ENSMerchant permissions / native ENSv2
Which wallet can
change what?
A role describes the action. Its resource describes where the action is allowed. Ops and Admin both have ROLE_SET_TEXT, but only Admin has it at the resolver root.
This is the permission model assigned by our registration contract and setup scripts. It is not a live audit of your wallet. Existing grants and parent administrators can add authority.
Platform → Provider → Service
Platform Owner manages provider registration. Each Provider Admin manages a dedicated native UserRegistry. Each Service Admin manages its service name and resolver, with scoped Ops and Treasury delegates. Permissions do not automatically inherit between these contracts.
The service grants below are implemented and fork-tested. Provider onboarding and complete role handovers are core scope, still awaiting implementation. Public setup remains pending.
Ops wallet
Three separate text-key grants
ROLE_SET_TEXT
Resource: keccak256(key): agent-endpoint[x402], description, avatar
Update the API URL, description and optional picture with their respective grants.
Cannot change payment settings, service status or delegate permissions with this grant.
Treasury wallet
Payment key
ROLE_SET_TEXT
Resource: keccak256("ens402.payment")
Update fixed price, recipient, network and token configuration.
Cannot change the API URL with this grant. The receiving wallet is a separate setting.
Service Admin
Resolver root
ROLE_SET_TEXT + ROLE_SET_TEXT_ADMIN
Resource: 0
Write all text records, including service status. Grant and revoke text writers.
This is a trusted administrator. Root permission overrides narrower key restrictions.
Verify the grants after setup.
Run pnpm ens:permissions:check with the service name and Admin, Ops and Treasury addresses. It resolves the actual native resolver and reads effective permissions at one block, including root overrides. Missing setup or an RPC error never counts as a pass.
The report checks required grants, forbidden text edits and text-administration privileges for those wallets. Fork tests also exercise allowed writes, rejected writes and revocation. This is a snapshot, not proof that grants cannot change later or that no other administrators exist.
Two contracts. Two kinds of control.
Registry: the name and its pointer
The service Admin receives ROLE_SET_RESOLVER, ROLE_SET_RESOLVER_ADMIN and ROLE_CAN_TRANSFER_ADMIN on the service name. These control its resolver pointer and native transfer.
Resolver: the service records
The same Admin receives root text writing and text administration. Ops and Treasury receive only their key-scoped setter grants. Each provider shares one resolver across its services.
Transferring the name does not transfer the separate resolver administrator. Parent or root administrators may retain native powers. One wallet can hold multiple roles. Its permissions are the union of those roles.
Platform setup comes first.
1. Parent name
The platform owner controls ens402.eth and points it to a native UserRegistry.
2. Child registry
The platform owner has ROLE_REGISTRAR and ROLE_REGISTRAR_ADMIN at its root. ServiceRegistrar receives ROLE_REGISTRAR only.
3. Service registration
ServiceRegistrar creates a resolver, sets records, delegates Ops/Treasury, hands text administration to the registrant and removes its own resolver privileges.
The platform owner and a service Admin are different responsibilities. They may be different wallets. The platform is not automatically given text permissions on each service resolver.