Chains and estates

Status: exploration, 2026-10-04; §3 and §5 revised the same day with the ENS v2 and ERC-8004 study. Companion to The estate and the federation. Everything marked live runs today; designed has a spec and a gate named; proposed is what this note recommends and no spec yet holds; open is a question it frames and does not decide.

An estate enforces on one chain. A chain is not an estate: several estates may stand on one, and an estate's residents may hold accounts on others. The estates on one chain and what they share there are a town (ap-town); towns on several chains, joined on public ground, are the federation (ap-federation). This note is the federation's problem statement: Substrate, estate, town, federation places it among the four scales. Some chains are private (faithchain, a Besu network one operator runs), some are public (Base). Both kinds are shared resources in the federation, and EVM chains come with a large cross-chain toolkit. The question is what, out of everything an estate holds, may travel between chains, and as what.

The answer is one sentence, and the rest of this note is its consequences. Authority is chain-local by construction; evidence and value cross a chain, authority never does. The second half of the note is what that leaves for a person who holds accounts on two chains, and what ERC-8004 and ENS v2 already know about joining them.

1. Three ways a chain and an estate relate

An estate on a public chain and an estate on a private chain are the same shape. The private chain buys a closed validator set and no gas market; the public chain buys the floor everyone can read. Nothing in the substrate prefers one: relaxedT4Floor is a deployer's stated choice, never inferred from block.chainid, after the estate's own chain was once on a hardcoded list and an audited invariant was off where it mattered.

2. Why authority is chain-local

This is not a policy. It is what the contracts do.

• A grant is signed into a chain. DelegationManager.DOMAIN_SEPARATOR is built from block.chainid and the
• Revocation is one read on one chain. isRevoked(hash) on the manager that issued the grant. There is no
• A payment mandate names its chain. PMT-INV-03 (spec 243): redeemable only on contextBinding.chain; a
• Custody is per account, and an account is per chain. AgentAccount + CustodyPolicy live where they were

The consequence for the federation: when a resident of estate A acts in estate C on another chain, the mandate is a C-chain delegation, issued by an account on C's chain, redeemed on C's chain (spec 410 §4.4). What A contributes is standing, as evidence: this subject holds a live grant in A; this subject is a member of this organization in A, proved against a root A anchored. C decides whether that standing earns admission. C's own mandate, verified per step, decides whether anything runs.

3. One principal, many chains

An address is chain-qualified. The identifier is CAIP-10, eip155:<chainId>:<address> (ADR-0008, CanonicalAgentId in types). The same hex on faithchain and on Base is two accounts with two custody states, two sets of grants and two revocation histories. Nothing makes them one principal except a statement signed by both. Spec 220 deferred that statement and kept CAIP-10 as the bridge.

3.1 What is lost without the binding

Nothing in authority, and most of what makes the person one person. Without it: cross-chain participation (spec 410 §4.4) stops at the edge, because A's root proves standing for eip155:34348:0x… and C's mandate is signed by eip155:8453:0x…, and nothing joins them; a passkey rotated out at her Home is still a live custodian on the Base account, so custody must be duplicated per chain or left stale; one history becomes two prov:Agents and a receipt anchored on Base is not provably hers; her name stops at its chain and someone else can hold mara.me on a second .me registry; rosters, stewardship and charteredUnder for a treasury drift per chain; and an ERC-8004 entry on a public chain cannot honestly point back at the account where custody is governed. The per-chain posture (a person on Base is a different account) is honest and cheap, and it forgoes all six. The binding is worth having if a Home person is meant to participate in an estate on another chain as herself; custody alone justifies it.

3.2 The recommended shape

Two existing standards have already solved the records half of this, from opposite ends. ERC-8004 keeps identity chain-local and joins the registrations in one self-published document, each entry verified by round trip, each wallet bound only by a signature it made. ENS v2 keeps one authoritative registry for a name, keys address records by chain, lets each chain's account claim the name in reverse, valid only when the forward record agrees, and resolves the name on other chains by proof against the home chain's state. Port both as principles in AP vocabulary; the custody half is ours to write.

1. Home and satellite accounts. One account per principal is the home account: where CustodyPolicy is
2. The card lists the accounts; each proves itself. The signed card (A2AAgentCardV1, the
3. One home registry per typed root; address records keyed by chain. mara.me belongs to the .me registry on
4. A reverse claim per chain, valid only with the forward. The satellite account on Base publishes "I am
5. Resolution elsewhere by proof, never by gateway trust. A verifying resolver on Base answers mara.me against
6. A deterministic authority set. We deploy accounts by CREATE2 already; deploy the factory, implementation,
7. Custody propagation, the part neither standard has. A rotation or a recovery at the home account reaches each

Nothing in 1–6 is authority. A satellite entry, a resolved address and a reverse claim are evidence a verifier reads. The act on Base still runs under a Base grant, verified per step.

4. What crosses a chain boundary

Two things never cross: a grant, and the read of its revocation. Everything else crosses as a reference, a signed list, a proof, an anchor, a transfer or a ceremony, and each of those is read from the live original on the chain that holds it.

5. The EVM standards, placed

The EVM world offers more cross-chain machinery than the federation needs. Four verdicts, and one test for all of them: does it carry authority? If it does, it is refused as a path. If it carries identity facts, we port the principle in our vocabulary. If it carries evidence or value, it is an adapter in a sibling repository (ADR-0037). If it is an identifier, we adopt it as is.

5.1 Identity: port the principle

5.2 Evidence and value: adapters

Ring 0 ships the fields these adapters carry and the contracts they read: a chain on every reference, a chain and an anchor on every receipt, a root per estate on public ground, a card that lists accounts with their proofs, a DelegationManager that refuses anything not signed into its own domain.

5.3 What none of them has

How a rotation or a recovery at the home account reaches a satellite. 8004 would transfer the token; ENS is a records layer and says nothing; the bridges carry messages, and a message is not a custody action. This is item 7 of §3.2, a CustodyPolicy ceremony per satellite, and it is the piece that must be specified by us before any of the ported principles is safe to rely on: a binding whose satellite can be left under a retired credential is a binding to a compromised account.

6. The scenario

Two estates on faithchain, one on Base. Mara's Home is in estate A.

Mara acts on an organization in estate B. Same chain. Her agent resolves the name, reads the records, is admitted at B's edge; the act parks at her Home; B verifies her grant on faithchain, where B already reads. This is the cross-estate act of the companion note, and it is live in part (reads and routed acts proven; G4–G6 pending).

Mara acts on an organization in estate C. Other chain. C's edge admits her agent on a presentation rooted in A's roots, read from Base, which is C's own chain. C's edge joins the proved subject to the actor through her card: the accounts[] entry for eip155:8453 carries a proof her Base satellite signed, and the satellite's atl:cardUri names the same card. The act parks at her Home in A, as before. The mandate is a Base delegation from the satellite, redeemed on Base. The receipt lands in her vault in A with apexec:estate naming C and an anchor in C's ReceiptAnchorRegistry on eip155:8453. If she rotated a passkey last week, the satellite's proof must have been re-signed by the propagation ceremony, or C's edge should treat the entry as stale (§3.2 item 7).

Mara's organization pays a supplier in C. Value. Her treasury on faithchain holds funds a private chain can hold; Base holds USDC. There is no public bridge between them. The move is either the organization's Base treasury paying from a Base balance under a Base mandate, or an operator-run bridge service the consortium of spec 410 §9 stands up, invoked by the treasury under a mandate bound to the destination chain. Either way the bridge never decides whether the payment was allowed; the mandate did, and the receipt says which chain it ran on.

7. Recommended order, and what stays open

Specs precede the code. The recommendation, in the order the dependencies run:

1. Amend spec 347: accounts[] on the canonical profile and the released card, the SatelliteAccountProofV1
2. Amend specs 215 and 346: atl:addr keyed by CAIP-2 chain; nativeId retired in its favour; one home registry
3. Extend spec 410 §4: a resolver storage root beside the live-grant and membership roots; the verifying resolver
4. Extend spec 410 §1 or write the custody-propagation spec: the satellite ceremony on rotation and recovery, the
5. The deterministic authority set in spec 407 D-03's chain-posture ADR: same addresses on every federation chain,
6. The Ring 1 ERC-8004 projection (D-10), now listing both accounts with their proofs.

Open, and not decided here:

• Which public L2 hosts public ground, and whether the authority set itself ever moves there (D-03; Base the
• A multi-chain indexer: the public graph with a CAIP-2 chain on every fact; one chain today.
• A bridge-aware mandate envelope for value (spec 243's successor ADR), and whether the consortium runs a bridge
• Order of proof: G4–G6 on faithnet-b first (one chain, two estates), then check:cross-estate-admission (two

8. Not figured out, and what ten chains would break

Everything above is drawn for two chains and three estates. Take the federation to ten chains, private and public, with estates on each, and the following are either unsolved or stop holding. Each is stated with what it would cost if ignored.

1. Revocation stops being "final and global." On one chain, revoke → refuse is one block and one read. Across

1. Custody propagation fans out, and the gap is the attack. One rotation at home is ten satellite ceremonies, each

1. Aggregate spend limits cannot be enforced across chains. Assets live only in treasuries (spec 420), and a

1. Private-chain evidence is not verifiable by strangers. A receipt anchored on faithchain names a chain whose RPC

1. "One home registry per typed root" has no home across federations. Within one federation the rule works. Two

1. Public ground becomes plural. Spec 410 §4 says one registry, many estates. Estates will anchor where their

1. Finality differs, and the substrate assumes it does not. QBFT is final at the block; a public L2 is soft-final

1. Contract generations drift per chain. Deterministic addresses need identical bytecode; faithchain runs
2. generation 1, Base Sepolia later generations, and approveDigest's semantics are generation 3. Ten chains at three

1. A public binding is a public correlation. CAIP-10 is omnidirectional by construction (spec 260); the card's

1. An estate's chain can die or fork. If a private chain is shut down, the home accounts, names, grants and

1. Operations multiply linearly and governance has no floor. Ten chains is ten RPC gateways, ten deployers, ten

1. The ontology has no word for it. prov:Agent is one IRI, and ours is one CAIP-10. A person with ten accounts

The shape that falls out of this list: a federation should be few chains, chosen, not many chains, accepted. One private chain per regulated posture, one public chain as ground and as the default public home, and a stated generation floor. Ten chains is not a goal; it is the stress test that shows which of the above must be solved before the third chain is added. Items 1, 2 and 3 are the ones that touch money and custody and should be solved first, and each needs a written window, a written race, and a written cap, before any code.

Sources

packages/contracts/src/agency/DelegationManager.sol (DOMAIN_SEPARATOR), AgentAccountFactory.sol (relaxedT4Floor, CREATE2), naming/AgentNameAttributeResolver.sol ("no multi-coin address records"), naming/AgentNameUniversalResolver.sol (round trip), spec 410 §1, §4 and §9, spec 407 D-03 / D-10, spec 347, specs 215 / 346, spec 243 PMT-INV-03, spec 220 §deferred, ADR-0008, ADR-0013, ADR-0037, ADR-0056; ERC-8004 (registration file, setAgentWallet), ENS v2 / ENSIP-9 / ENSIP-11 / ENSIP-19 / ENSIP-10, ERC-3668, ERC-7930, ERC-7828; The estate and the federation.