Forum Username Linking
The Problem
Governance platforms need to connect on-chain wallets to the forum identities of the people behind them. Right now, every service that needs this mapping — Karma, Tally, Curia, Agora, Snapshot — solves it independently.
Each platform asks delegates to submit their forum username through a platform-specific flow. The result is a fragmented landscape where the same delegate may have linked their Discourse account to different wallets on different platforms, with no clear way for downstream consumers to know which one is authoritative.
Proposed Solution
ENS metadata provides a canonical place to express this relationship. A delegate sets their forum username once, as a record on their ENS name. Every platform that needs the mapping reads from the same on-chain source.
No proprietary API. No platform-specific submission flow. One update propagates everywhere.
Consider the latest Delegate schema and the patternProperty ^forum-handle(\\[[^\\]]+\\])?$ which allows the user to specifiy multiple forum handles.
delegate.alice.eth
└── forum-handle[uniswap.eth] = "alice" # Uniswap forum username
└── forum-handle[ens.eth] = "alice576" # ENS forum usernameBecause ENS records are public and permissionlessly readable, any governance tool can resolve the relationship without further interactions.
Reverse lookup
To find all users who have registered their ENS forum username, we could index the forum-handle[ens.eth] text record.
Standard ENS TextChanged filtering will surface all relevant records.
Verification
Text records set by ENS name owners are self-asserted by default.
For stronger guarantees a forum-proof[ens.eth] or forum-attestation[ens.eth] could also be introduced using zkTLS or EAS.
Regardless of the approach the ENS remains the canonical source.
Why This Matters for DAOs
Governance tooling
Many governance platforms currently each maintain their own wallet-to-forum-username mapping. By reading from ENS, they can share a single source of truth. Delegates update once; every platform reflects it.
Conflict resolution
When platforms disagree on which wallet belongs to a forum username, the ENS record provides a tiebreaker. The ENS name owner — who controls the private key — is the authoritative source. Platforms can surface a warning when their cached mapping diverges from the ENS record.
Real-World Context
This use case emerged from a discussion on the Arbitrum governance forum, where community members observed that Karma and Curia were independently building forum-to-wallet verification, creating the exact fragmentation problem ENS text records are designed to solve:
"I think we should try to avoid getting into this kind of situation… delegates could also do something simpler, which is to add a record to their ENS names, specifying their Arbitrum Forum username." — paulofonseca.eth, Arbitrum Forum
The ENS Organizational Registry formalises what paulofonseca.eth was already doing manually, turning an informal convention into a standardised, indexable, composable field.
Related
- Delegate schemas — the schema type where forum records appear