Inheritable Mandates

Demo

About

CONTINUITY TRACK DISCLOSURE. This project is not new. The repository opened on 30 July 2026 and, before this event began, already carried: the ERC-8370 specification under editor review as pull request #1930 against ethereum/ERCs; a public discussion thread with 47 messages of review; thirteen contracts deployed on Base Sepolia; a reference contract on Base mainnet verified on Sourcify; 142 machine tests; a survey of 271 ERCs with its method published; and 61 commits of public, unedited history. What was built during the event is reclamation, described below, committed on 8 September and deployed the same evening. The separation between pre-existing and new work is stated in the repository README, in the demo video, and in this description. When an autonomous agent holds money on-chain, it can spawn copies of itself. Every guardrail we have — session keys, spending caps, policy engines — is attached to a single account. None of them follows that account's children. So the agent clones itself, the money follows, and the limits do not. ERC-8370 welds a mandate to the agent's on-chain identity: a spend cap, an expiry, a reproduction counter, an allowed-payee list and a kill switch. Every clause is inherited by any child the agent spawns, and every clause can only ever tighten. A child's cap is no higher, its expiry no later, its payees a subset. Editing your own clauses changes your identity, so nobody recognises you any more. Reproduction is bounded separately by a telomere — a generation counter that only ever counts down, with no operation anywhere that raises it. At zero, a branch stops reproducing. Built during ETHOnline 2026 under the Continuity Track: reclamation. A parent's budget is divided among its children, and that allocation only ever went up — a child that died, expired or frozen, held its slice of the parent's budget forever. The lineage bled without anyone spending anything. reclaim returns a dead child's unallocated share, on a death condition reachable without the child's cooperation, because a dead child cannot be asked to agree. Forty ether, locked before, released for 59,694 gas. Death is deliberately local, not inherited: a healthy child under a frozen parent cannot act, but it is not dead, and its budget is not yours to take. That refusal was sent on-chain so it can be cited rather than described.

How it's made

Solidity 0.8.24, Foundry for the test suite, TypeScript with viem for deployment and on-chain exercise. Thirteen contracts run on Base Sepolia; a reference contract is on Base mainnet, verified on Sourcify. 149 machine tests gate every commit through a pre-commit hook that refuses the commit when they fail. The invariant suite alone rejects a child that renews its own telomere, one that disables an inherited lease, one that widens its cap, one that names a payee outside its parent's list, and one whose expiry outlives its parent's. The method is adversarial rather than confirmatory. Four independent model families were given the deployed source and asked to break it, with no hint as to which checks existed. Every attack they proposed was executed against the deployed contract. The chain decided, not the model. The fifth revision entered that process with seven defects — six found by an adversarial model, one by the repository's own bench, an agent that kept spending for 150 days past a lapsed ancestor. All seven were closed before the contract touched a chain. The hardest single decision in the new work was that isDead must not be the negation of isActive. isActive walks the ancestor chain, so it reports false for a perfectly healthy child whose ancestor died; reclaiming on that basis would let a freeze at the root confiscate the budget of descendants that did nothing. The second was that reclamation writes nothing into the child's mandate. Zeroing a reclaimed child's cap is the intuitive way to mark it spent, and it would change mandateRoot — the child's identity — detaching any ERC-8312 envelope pinned to it. Reclamation is a bookkeeping write, never a clause write. AI assistance is documented file by file in AI-USAGE.md, including what it did not do: choose the problem.