I’m interested in proposing a verification protocol for ENS, aimed at enhancing the utility and establishing verifiability of text records. However, before moving forward, I’m interested in gaining insight from the ENS developer community, if possible.
Abstract
The Verified Text Record (VTR) protocol establishes a decentralized method for issuing, authenticating, and, when necessary, revoking/invalidating text records. It ensures that ENS users can easily verify the legitimacy of user affiliations, credentials and more via text records.
The development of such concept can potentially be utilized by a wide-range of applications, from verification badges, to certifications and a bunch of other neat things which have the potential to further solidify (
) the ENS ecosystem’s credibility and multifunctionality by adding additional layers of verification.
Note: for clarity, this isn’t a proposal to change the existing ability for users to freely create text records. This proposal instead aims to develop an overlay system on ENS that empowers individuals, entities, and organizations to issue verifiable text records.
Problems:
Potential Misrepresentation: As ENS gains adoption, the likelihood of misuse or misrepresentation within text records increases. Users can claim false affiliations, attempt to assume the identities of others, or devise other, more creatively harmful forms of manipulation if there are no verification systems in place.
Diminished Reliability: Text records have the potential to be a goldmine of reliable information. But, if records are saturated with unverified data, their reliability takes a hit. Users may begin to question the utility of these records for the purpose of identification or affiliation if they cannot trust their authenticity.
Breakdown of Proposed Solution:
Smart Contract Layer: This would contain the logic for issuing, migrating/transferring, verifying, and, when necessary, revoking records. Each VTR record is tethered to this contract.
Open Issuance: Any entity or individual can deploy a VTR issuance contract and begin issuing VTR text records. This promotes fairness and decentralization, removing the need for any centralized body to oversee or control the issuance… I’m totally open to different perspectives here, but I don’t see a downside to keeping issuance open, as much like diplomas or other certifications, the reputation or credibility of the issuer is what holds importance.
Public Ledger of Verified Records: Users can easily reference this ledger to validate any VTR claims on ENS, and possible integrators can streamline this check.
Revocation Mechanism: Issuers, or those who actually deploy the contracts have the option to implement a function which can revoke certain records. Whether it’s due to a change in association, like an employee getting fired, or other conditions, the system would be dynamic enough to cater to these real-world nuances. Implementation of this function should be based on whether the record is conditional or permanent. This function could be an automated process based on predefined conditions, require a manual trigger or even a DAO vote depending on how the contract is set up.
Potential Use Cases
Verification Badges:
Entities can employ VTRs to grant verification badges, acting as a testament to their legitimacy on the ENS platform.
Endorsements:
Communities, groups, or DAOs can issue VTRs, as endorsements or recognition.
Accreditation Records:
Educational entities could dispense digital diplomas or certificates using VTR.
Proof of Attendance:
Event organizers can use VTRs as a testament to attendance.
Possible Smart Contract Design and Functions:
Contract Initialization:
The VTR smart contract will be initialized with the issuer’s details. Parameters could be issuer ENS name, description, etc.
Possible Functions:
-
issueRecord(address recipient, string memory recordText): Allows issuer to issue a new VTR to a specific ENS name. The record’s content is stored and tied to the recipient’s address. -
revokeRecord(address recipient): An optional function which allows retraction of an issued VTR from a specific address. **Only the issuer or addresses with granted permissions can call this function. -
validateRecord(address queryAddress): A public function that can be invoked by anyone to verify the authenticity of a VTR tied to a specific ENS address. -
updateIssuerDetails(string memory newName, string memory newDescription): Lets the issuer update details, ensuring identity remains relevant and current. -
grantPermission(address delegate): The issuer can grant permission to other addresses, authorizing them to issue or revoke VTRs on the issuer’s behalf. -
revokePermission(address delegate): Reverses the permissions previously granted to an address. -
transferRecord(address from, address to): Facilitates the transfer of an issued VTR from one address to another. Only the current owner of the VTR or addresses with granted permissions can call this function. This ensures records can be migrated as needed without revoking and reissuing…
Linking VTR to ENS
Once a VTR is issued to an ENS address, a link is established between the record’s content and the recipient’s ENS profile. This is done using the recipient’s address as a key… Ideally, there could be a “claiming” process, where the text record could be automatically populated within the user profile through a UI. However, at its most basic level, users can manually create the record, and while crude/rudimentary, it should be considered verifiable.
Retrieval of VTR on ENS Profile:
Users can showcase their VTRs on their ENS profile. When someone checks an ENS profile with an VTR, they can cross-reference the record with the VTR contract to ensure its authenticity- though, this is a bad UX without native integration of ENS manager and/or other platform integration.
Update Mechanism:
When a record is revoked, the link between the VTR and ENS profile is broken. The record no longer shows up as validated when cross-referenced against the VTR smart contract… In the most ideal scenario- future updates to the ENS manager app could incorporate a built-in VTR checker. 
This would automatically update and check the active status of an VTR, streamlining the verification process and enhancing UX.
Integration with Other Platforms:
Social Media:
Integration with social media platforms, like Farcaster could allow users to display their VTRs directly on their profiles, automatically providing a quick cross-platform verification method.
DAO Platforms:
For DAOs, VTR can be incorporated to provide verifiable badges for members, signifying roles, achievements, etc.
Networking Platforms:
On platforms like LinkedIn (or the next LinkedIn), users can showcase their VTRs as badges of authenticity, verifying past roles, achievements, etc.
Academic or Professional Certifications:
Educational institutions and certification programs could adopt VTR to provide verifiable badges for their alumni and certified users.
Integration with Wallets and DApps:
Wallets or DApps could incorporate an VTR checker tool, allowing users to quickly verify the authenticity of any VTR they encounter.
With these potential integrations, I believe that the VTR system has the potential to set a new standard for verification and authentication… Though, I absolutely may be missing something… which is why I am here.
Conclusion
My thinking is that the combination of ENS and VTR can enhance user trust. When someone looks up an ENS name and sees a VTR attached, they know immediately (assuming cross-referencing is integrated in wallets/name manager,etc.) that the claim has been verified without having to rely on external validators. This also means that bad actors find it difficult to forge their affiliations.
Unlike NFTs, VTRs leverage the existing structure of ENS to become a primary source of truth, eliminating the need to sift through NFTs in a user’s wallet to validate association and/or claims… So, in my humble opinion, VTRs are better than NFTs for verification purposes since they are directly linked to an individual’s primary Ethereum identity, offers revocation capabilities, and don’t rely on external storage systems.
But like all ideas, the actual potential of VTRs can only be realized with community involvement. This post serves as an open invitation for discussion. Any ideas, insights, critiques, and contributions are very much encouraged.
Thanks.