Filling out your delegate information

This guide explains how to publish your delegate information as ENS metadata, turning your ENS name into a single source of truth for your online delegate identity.

Step 1: Choose the right ENS node

Delegate records should live on the ENS name that resolves to the address holding your voting power. Governance tools trace delegation on-chain from token balances to an address, then reverse-resolve that address to find your ENS name. If your metadata records are on a different name/subname, they may be hard to find.

Here are step-by-step instructions on how to properly set up your delegate information, using ensmetadata.app and app.ens.domains to directly query on-chain data.

1. Identify the address that holds your voting power. This is the address you use to vote on proposals.
2. Check which ENS name resolves to that address. If you already have an ENS name configured, open app.ens.domains and search for your name. The name whose forward record (the ETH address record) points to your voting address is the correct node to use. If you don't yet have an ENS name configured, you can make one now.
3. Confirm the reverse record matches. For governance tools to find you, the address should also have a primary ENS name set, and that primary name should be the same node you are editing. If the reverse record is missing or points somewhere else, set it in the ENS app under My Names → Set as primary ENS.
4. Use a subname if you want to keep delegate data separate. Many users prefer to isolate delegate metadata on a dedicated subname such as delegate.alice.eth and point its address record at their voting wallet. This keeps your main name's records uncluttered. Just make sure the subname's address record and reverse record both point at the voting address.

Step 2: Add your delegate information

1. You are now ready to add your delegate information via ensmetadata.app. Connect your wallet, and navigate to the node you identified in step 2 above.
2. Under Schema, select Delegate.
3. The most common fields will appear automatically. To add additional fields, choose "+ Add Optional Field" and select from the list.

The statement, conflict-of-interest, and forum-handle fields act as fallbacks that any DAO can read when you haven't written something specific for them.

Step 3: Add DAO-specific statements and conflict-of-interest

If you delegate in multiple DAOs, you'll usually want a different statement and conflict-of-interest declaration for each one. The delegate schema supports this through parametrised keys, where the parameter is the DAO's own ENS name.

Add one record per DAO you participate in:

delegate.alice.eth
  ├── statement[uniswap.eth]            = "My Uniswap priorities are..."
  ├── statement[ens.eth]                = "For ENS governance I focus on..."
  ├── conflict-of-interest[uniswap.eth] = "I hold positions in..."
  ├── conflict-of-interest[ens.eth]     = "I am a contributor to..."
  ├── forum-handle[uniswap.eth]         = "alice"
  └── forum-handle[ens.eth]             = "alice576"

For now, adding these variants is a manual process:

1. With the node selected, click the "+ Record" button at the bottom of the metadata editing drawer.
2. Enter the parametrised key exactly as shown (for example, statement[ens.eth]) with the DAO's full ENS name in square brackets.
3. Paste your statement or declaration as the value for that record, and save the changes.
4. Repeat for each DAO you are active in, and then broadcast the transaction to update your records.

Discovering delegates

Once records are live, any governance tool can find and display them. Typical on-chain voting systems make it possible to discover a list of all addresses that currently hold voting power. Each of those addresses can then be reverse-resolved to its primary ENS name, connecting the on-chain voting power to the delegate records published under that name.

Related

• Delegate schemas