Repository navigation
[Feat]: A reclaimed name keeps serving the previous owner's records and subnames #220
Description
Component
Resolver
Priority
P1
Summary
Resolver records and subnames are keyed by node, so they outlive a change of owner. After a name is released and reclaimed by a new owner:
DotnsResolver.addressOf,DotnsContentResolver.contenthashandDotnsContentResolver.textstill return what the previous owner wrote, so payments sent to the name go to the previous owner. The new owner cannot reliably clear these records, because text records cannot be listed.- Its subnames stay with the holders the previous owner gave them to, with their records, and the new owner can only take them back one by one.
This affects names that can be released, which today means free-tier names: device and personhood names are soulbound.
Proposal
Decided rule:
- Release cleans up. When
DotnsNameEscrow.releasetakes a name, its records read as unset, and its subnames, with their records, stop resolving. Whoever gets the name next, a new owner throughreclaimor the same holder throughredeem, starts clean. - Transfer keeps everything. A plain transfer carries records and subnames over to the new owner, who overwrites what they need.
Acceptance criteria
- After
release, every address, content hash and text record of the name reads as unset, and every subname beneath it, at any depth, has no owner and no records. - After a later
reclaimorredeem, the name still starts with no records and no subnames. - After a transfer, every record and subname is unchanged.
- Records and subnames written before the upgrade stay readable until the name is released.
- Tests cover each record type and nested subnames for release, reclaim, redeem and transfer.
Activity
re-gius commentedon Aug 12, 2026
This can be also seen as a bug - this is why I flagged it as P0
sphamjoli commentedon Aug 17, 2026
@re-gius how would you resolve this? we tried an on chain solution but it was a very messy solution, the ideal path was to solve this at the tooling level.
re-gius commentedon Aug 17, 2026
I would be satisfied even with just invalidating older records: we need a version number, one
uint64per node, bumped on every ownership change, and resolvers treat anything written before it as unset. This also requires stamping each record with this version number at write time and just compare on read. Since that is a read-side filter, no write paths change and nothing needs migrating.If anyone has better ideas, I'm open!
EDIT: this need special care for sub-domains
GHkrishna commentedon Aug 31, 2026
Since for v1 launch, we will only manage lite names and no full pop registrations. This also implies there won't be any transfer of names. For this reason, we have updated the priority for this issue.
re-gius commentedon Sep 4, 2026
Removing from milestone - transfers will be supported in the next upgrade
[-][Feat]: A re-registered or transferred name keeps serving the previous owner's records[/-][+][Feat]: A reclaimed name keeps serving the previous owner's records[/+][-][Feat]: A reclaimed name keeps serving the previous owner's records[/-][+][Feat]: A reclaimed name keeps serving the previous owner's records and subnames[/+]re-gius commentedon Oct 13, 2026
Gav confirmed the rule in the description. When a name is released, the holder gets the deposit back, and the name's records and subnames are deleted. A transfer clears nothing: records, subnames and the deposit all move to the new owner, who can later release the name to claim the deposit.