ENS Drive
ENS Drive · Google Drive–style sharing for ENS names

Share ENS names like a folder.

Share a name with a team, and the team can manage every name under it — including names added later, and names in the folders below. Built into ENSv2's own access control, replacing nothing.

Try it live ↓ Real contracts on the ENSv2 beta (Sepolia) · every click is a transaction
✓The directory tree

ENSv2 already built it. Every name can have its own registry, so names nest like folders: orbit-dao.eth › protocol › vault. But every folder is a separate registry with its own permission list — so a team's access multiplies with every folder.

✗The sharing layer

Missing. Permissions are granted one address on one name. There's no way to share a folder with a group.

A web3 org's team of 5 managing 20 names across 3 folders: 300 grants, and 60 revokes when someone leaves. (ENSv2's registry-wide grants cut it to 15 — but every join or leave still touches every folder. A worked example.)

→ENS Drive adds it

With Cascade, a permission layer on ENSv2's own access control using relationship-based access control (ReBAC): a name trusts a team, the team's members inherit, and sharing flows down the tree — checked live, nothing copied.

In ENS today

Like sharing each file with each person.

vaultoraclebridgeAlicegrantgrantgrantBobgrantgrantgrant

Every ENS permission is one address on one name. Two people, three names: six separate grants. A new name needs new grants for everyone; someone leaving means finding and revoking each one — in every registry of the tree.

With ENS Drive

Like sharing the folder with a group.

orbit-dao.eth→ one grant →security-council→every name below

One grant covers every name under the folder, today's and tomorrow's, and flows into the folders below. Joining or leaving is one change to the team. Everything ENSv2's access control already does keeps working exactly as before.

Try it · live on Sepolia

Share a folder, and everything below follows.

1/6You run orbit-dao. Alex just joined as a contributor — every click is a real transaction. First, Alex tries to edit vault: nobody has shared anything with them.
Reading the contracts on Sepolia…

The setup: protocol is shared with core-devs, and orbit-dao.eth — the folder above — with security-council, which includes auditors. Two shares, made once. Everything below is just who's in which team.

NameAlex can…
  • vaultvault.protocol.orbit-dao.eth
  • oracleoracle.protocol.orbit-dao.eth
  • bridgebridge.protocol.orbit-dao.eth

In ENS terms: folders = names with their own registries (orbit-dao.eth, protocol.orbit-dao.eth) · file = a subname · groups = team contracts (security-council is a NestedTeam containing auditors) · “can edit” = the SET_SUBREGISTRY role, granted to core-devs on protocol and to security-council on orbit-dao.eth · the switch = CascadeSubregistryV2.setDepth(2 / 1). Every action is a real transaction on the ENSv2 beta (Sepolia).

Under the hood

One new registry. ENS's own check.

ENS Drive's permission layer is Cascade. ENS's own code still decides every write; Cascade changes the answer to the one question it asks — “does this account have this role here?” — by walking up the folders and asking each shared team about the caller.

STOCK ENSV2.eth registryENS's ownshares orbit-dao with security-council · edit, set resolverSTOCK PERMISSIONEDREGISTRYorbit-dao.ethOrgRegistryshares protocol with core-devs · editNEW · THE ONLY NEW LOGICprotocol.orbit-dao.ethCascadeSubregistryV2teams: core-devs, security-council · depth 2overrides the role lookup: _getRoles, _checkRolessubregistrysubregistryvaultoraclebridgethe files: the operator owns themwith renew only, nobody holds edit1does the folder above point back down?getSubregistry ✓ · roles(protocol, team)2step up one folder, check againgetParent · getSubregistry ✓ · roles(orbit-dao, team)3is the caller in the team?isMember · only if its grant could helpTEAMS · PLAIN EACcore-devsTeamRegistrysecurity-councilNestedTeamauditorsTeamRegistryAlex

Scroll sideways inside the diagram to see the teams →

Where names live: each name points to the registry holding its children. Stock ENSv2.One write, walking up: read-only, gas-capped calls, in order. Owners stop before step 1; everyone stops the moment access is proven.The only new contract. Everything else is ENS's own code or a plain roster.
orbit-dao.eth registrystock ENSv2

An ordinary PermissionedRegistry, unmodified.

Holds
  • ·the name protocol (its files live in CascadeSubregistryV2)
  • ·the grant: core-devs can edit on protocol
  • ·above it, the .eth registry holds security-council's grant on orbit-dao
Sepolia0x6e1d…fc48
CascadeSubregistryV2the one new registry

The registry for protocol.orbit-dao.eth — ENS's own PermissionedRegistry, with the role lookup overridden.

Holds
  • ·the files vault, oracle, bridge
  • ·its teams: core-devs, security-council (up to 4)
  • ·how many folders up sharing flows (depth 1–3)
Sepolia0x7aa1…d0a3
Team contractsplain EAC

Rosters. core-devs and auditors are TeamRegistry; security-council is a NestedTeam that includes auditors.

Holds
  • ·one bit per person: member on / off
  • ·security-council: its sub-teams (auditors)
  • ·Hats / Safe adapters fit the same one-function interface
Sepolia0xce0b…acfa
What happens when Alex (in auditors) edits a file
  1. 1Alex callsCascadeSubregistryV2.setSubregistry(vault)
  2. 2ENS checksthe name exists and hasn't expired, then asks for the role
  3. 3Own roles?none stored for Alex — keep going (owners stop here)
  4. 4Level 1 · protocolorbit-dao registry points back down ✓ · core-devs' grant: can edit · is Alex in core-devs? no
  5. 5Level 2 · orbit-dao.eth.eth registry points back down ✓ · security-council's grant: can edit · is Alex in security-council? → auditors: yes
  6. 6Resultcovered → stop and allow · nothing covers it → reverted by ENS's own check

Steps 3–5 are Cascade. Every outside call is read-only and gas-capped; if any fails, it counts as “no”. A team is only asked about membership if its grant could help, and the walk stops as soon as the role is covered.

How the override works
EnhancedAccessControl
ENS's access control — role lookup marked virtual
PermissionedRegistry
overrides it: approved operators get the owner's roles
CascadeSubregistryV2
overrides it again: members inherit what shared folders grant their team

ENS's functions are unchanged. Because the lookup is virtual, every check inside ENS's code runs Cascade's version, which runs ENS's own first and only ever adds roles — never admin roles, never registry-wide roles. Proven with a symbolic checker for all inputs, and fuzzed against a full recomputation.

Also live: the one-folder version (CascadeSubregistry on devops.acme-corp.eth) — the “One folder” tab above. The .eth registry: 0x1d7883…

More detail