This document describes a system for representing organizational structures on-chain using the Ethereum Name Service (ENS) hierarchical naming system. The system leverages ENS's tree structure to map organizational relationships and uses standardized metadata to describe each organizational entity's role.
We introduce two new global text record key names. Both types of record can be used in tandem for each node (recommended) or a node can use just one of them.
class recordThis record identifies the organizational role of the node, selecting from a list of predefined options. These are mainly provided to give human-readable context and allow for quick sorting and identification of nodes:
| Class name | Description |
|---|---|
| Agent | This node represents an autonomous software-controlled entity |
| Application | This node represents a software application, service, or product |
| Committee | This node represents a formal group with delegated authority to make decisions or provide oversight within a defined scope |
| Contract | This node represents, and resolves to, a smart contract |
| Council | This node represents a high-level governance body with broad strategic authority and stewardship responsibilities |
| Delegate | This node represents a voter in on-chain governance, who may or may not have been delegated voting power from others |
| Group | This node represents a logical grouping of multiple child nodes |
| Org | This node represents an organization or sub-organization within a larger entity |
| Person | This node represents an individual human |
| Treasury | This node represents an account for funds that are collectively owned and/or managed |
| Wallet | This node's main purpose is to send, receive, and/or store funds |
| Workgroup | This node represents an operational team focused on executing tasks or work within a specific domain |
schema recordThis record contains a URI pointing to a JSON schema, following a specific format, which describes what additional attributes are expected to be added to the node, including formatting types and other machine-readable information.
An automated system wanting detailed information about the node can check for the existence of a schema record, and if it exists, it will know what additional attributes are expected to be found attached to that node and can query them directly.
If the node has additional text records set for some other purpose, they can safely be ignored if they are not referenced in the schema declared for that node.
Schemas that are stored on IPFS will each have a unique identifier. Dashboards and other visualization systems could validate and cache well-known schemas by URI, and any nodes that make use of an unknown schema could be omitted or flagged for review. This allows for consistency across the board when displaying and interpreting node metadata.
The combination of the two types of records, together with ENS’s parent-child relationship structure, allows us to present details for an entire ENS name domain in various ways:
A hierarchical view of an entire ENS name can be displayed, highlighting the class value of each node, allowing for a human-friendly overview of the organizational structure.