Address registry: immutable root, mutable bytes32 bindings on Zoltu, plus a lib to read it and a post-deploy check

[thedavidmeister]

The problem

Deterministic deploys and configured addresses are in tension. The CREATE2
address is a function of the creation code, so any address baked into a contract
is part of its identity — change the address, and every future deployment lands
somewhere else. So configured addresses get hardcoded, one copy per repo, and
can never be changed without moving deployments.

Initial ownership is the case that prompted this — src/lib/LibRainDeploy.sol
contains no notion of an owner, so every repo hardcodes one — but the problem is
not specific to owners, and neither is the fix.

The concrete — here

Deployed via Zoltu, same address on every network.

• An immutable root authority, hardcoded.
• mapping(bytes32 name => address). Root binds a name, and may re-bind one it
  has already bound.
• Reverts on an unset name, so no caller has to remember to check.
• Rejects the zero address, because an unset name reads as zero, so a zero
  binding would be a name that is both bound and unreadable.

That is the whole contract. No removal, no upgrade, no authority besides root.

It lives here rather than in a separate concrete repo. The address and codehash
are a function of the creation code, which is a function of the compiler
settings that compiled it; keeping the concrete, the settings and the pins in
one repo means there is no boundary across which they can silently diverge, and
nothing has to depend on another deploy repo to get them.

Bindings are mutable

The name a consumer resolves is in that consumer's creation code. A binding
welded to one address forever therefore cannot express an ordinary rotation of
an owning Safe: it would need a new name, which means new creation code and a
new deterministic address. That is the exact problem this exists to remove, just
relocated.

Write-once bought less than it looked like it did. It protected bindings on
chains already in use from a compromised root, and it never protected a fresh
chain, because an attacker who is root registers the name there first either
way. So it cost ordinary rotation to buy safety only on chains already
established.

Mutability costs nothing already deployed. A consumer resolves a name once,
in its constructor, and stores the answer; it never consults the registry again.
Re-binding a name changes what the next deployment resolves and nothing else,
which makes a rotation a deliberate migration rather than a silent, retroactive
change to live contracts.

The lib — here

Reads the registry for a given name, and verifies its codehash the way
ZOLTU_FACTORY_CODEHASH is checked here today.

That is all it does. What a consumer resolves a name for, and when — an owner in
a constructor or an initializer, under Ownable or RBAC, or anything else
entirely — is its own business.

The check — after the deploy, not before

A check against the registry before a deploy would be TOCTOU against a mutable
value and worth nothing: the binding can move between the check and the
constructor that consumes it.

The working model is: deploy as step 1, verify, then migrate onto it as step 2,
never using an untested deployment. So verification runs after the deploy,
against the value the deployed contract has already snapshotted. That is settled
state and cannot move under the check.

LibRainDeploy already runs the multi-network broadcast, so the cross-network
half of that belongs beside it rather than in every consumer's deploy script.
But only the consumer knows where it stored what it resolved, so the split is:
the consumer supplies the reads, and LibRainDeploy supplies the fork loop and
the comparison. It is deliberately source-agnostic — it asserts that the
deployed contract holds the expected address, not where that address came from,
because re-reading the registry would assert a value that can move rather than
the value the deployment actually took.

The security model

Compromising root cannot touch anything already deployed. Every consumer
snapshotted its address at construction and never reads the registry again, so
there is no live contract a re-binding can reach.

What a compromised root can do is poison a future deployment, by pointing a
name at an address it controls so that the next deploy snapshots that address.
Post-deploy verification is what catches it: the deployment is checked before
anything depends on it, so the outcome is a burned deterministic address,
discovered while nothing points at it, rather than a compromise.

Nothing a bound address does can break determinism. No resolved address is
in any creation code, so whatever a consumer does with one afterwards —
transferring an ownership, revoking a role — moves no address anywhere.

[thedavidmeister]

Prior art: no ERC to implement here

Checked the existing address-registry standards. None fits, and the two closest are both mutable and owner-administered — which is the property this design specifically refuses.

ERC-6224: Contracts Dependencies Registry — the closest by shape, since it exposes getContract(string name) returns (address) and hasContract(string name). But it is a dependency-injection container for upgradeable systems, not a binding registry: addProxyContract, removeContract, upgradeContract, upgradeContractAndCall, injectDependencies, all gated by OwnableUpgradeable with a separate ProxyUpgrader holding upgrade authority. Mutability is the whole point of it. Adopting it would mean adopting exactly what turns the cross-network check into a race.

ERC-1820: Pseudo-introspection Registry Contract (Final) — its deployment technique is the same idea we get from Zoltu: keyless deployment from a single-use account with no known private key, using a transaction whose signature r/s are repeating 1820 patterns, so the same bytecode lands at 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24 on every chain. Good precedent for the deterministic-address half, which we already have.

Its semantics do not transfer. The key is (address _addr, bytes32 _interfaceHash) → implementer, answering "who implements interface I for account A". There is no global name → address binding; using it here would mean co-opting the _addr slot as a namespace, which is a misuse rather than an implementation.

ERC-926: Address metadata registry — maps an address to a metadata provider (provider(address target), setProvider). Address → provider, not name → address.

ERC-725Y — a generic key/value store, but per-identity: it lives on each identity contract and is mutable by that identity. Not a shared registry.

Conclusion: nothing to implement. A standard would add surface to a ~100 LOC contract for interoperability nobody is asking for, and the deterministic-address problem the one relevant standard solves is already solved here by Zoltu.

[thedavidmeister]

Note on the prior-art comment above, since the design it was assessed against has changed.

Its conclusion still holds — there is no ERC to implement here — but one of its arguments no longer does. It disqualified ERC-6224 partly on the grounds that "mutability is the whole point of it", against a design that refused mutability. Bindings are now mutable, so that particular objection is gone and 6224 is the closest fit it was already assessed as.

What still rules it out is surface, not mutability. 6224 is a dependency-injection container for upgradeable systems: addProxyContract, removeContract, upgradeContract, upgradeContractAndCall, injectDependencies, gated by OwnableUpgradeable with a separate ProxyUpgrader holding upgrade authority, keyed by string. Adopting it means adopting proxy-upgrade machinery for a contract that is one mapping, one writer and one reverting reader. ERC-1820, ERC-926 and ERC-725Y are unaffected by the change and remain the wrong shape for the reasons given.