> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ixo.world/llms.txt
> Use this file to discover all available pages before exploring further.

# Emerging Platform domain registration

> Register and manage digital twin domains in the Emerging Platform for any solution implementation.

The **Emerging Platform** uses digital twin domains as reusable identity and state containers. This page is platform-scoped and applies across solutions, including **Emerging Household Energy**.

## Domain Types

<CardGroup>
  <Card title="Organisations" icon="building">
    Legal entities managing clean cooking projects
  </Card>

  <Card title="Projects" icon="folder">
    Mitigation activities and programs
  </Card>

  <Card title="Assets" icon="box">
    Physical devices and tokenized outcomes
  </Card>

  <Card title="Protocols" icon="scroll">
    Templates and governance rules
  </Card>

  <Card title="Oracles" icon="brain">
    AI-enabled verification services
  </Card>
</CardGroup>

## Domain Structure

### Core Properties

<AccordionGroup>
  <Accordion title="Digital Identifier (DID)">
    * Follows Interchain Identifier methodology
    * Self-sovereign and cryptographically secure
    * Globally unique and resolvable
    * Permanent and immutable
  </Accordion>

  <Accordion title="Entity Metadata">
    * Verification credentials
    * Relayer node assignment
    * Validity period
    * Operational status
    * Verification state
  </Accordion>

  <Accordion title="Service Configuration">
    * API endpoints
    * Data streams
    * Oracle integrations
    * Payment services
  </Accordion>
</AccordionGroup>

## Registration Process

### 1. Protocol Selection

<CardGroup>
  <Card title="Browse Templates" icon="list">
    View available protocol templates
  </Card>

  <Card title="Check Requirements" icon="clipboard-check">
    Review domain specifications
  </Card>

  <Card title="Select Protocol" icon="check">
    Choose appropriate template
  </Card>
</CardGroup>

### 2. Domain Creation

<AccordionGroup>
  <Accordion title="Entity Document">
    ```json theme={"system"}
    {
      "@context": {
        "class": "did:ixo:entity:abc123",
        "type": "CleanCookingProject",
        "version": "1.0"
      },
      "credentials": [],
      "relayerNode": "did:ixo:entity:relayer123",
      "validFrom": "2024-01-01T00:00:00Z",
      "status": "active"
    }
    ```
  </Accordion>

  <Accordion title="Required Fields">
    * Protocol class reference
    * Entity type specification
    * Relayer node assignment
    * Validity period (optional)
    * Initial status
  </Accordion>
</AccordionGroup>

### 3. Verification Flow

<CardGroup>
  <Card title="Submission" icon="paper-plane">
    Submit domain proposal to DAO
  </Card>

  <Card title="Governance" icon="users">
    Community verification voting
  </Card>

  <Card title="Execution" icon="check-double">
    Automatic verification on approval
  </Card>
</CardGroup>

## Governance and DAO workflow

**What “proposal to DAO” means here** — A domain change (new entity, protocol class, relayer, or material metadata) is packaged as a **proposal**: voters decide whether the network should treat that domain as verified and active for the intended program.

1. **Draft** — Complete the entity document and evidence your template requires (controllers, relayer, protocol DID, optional credentials). Use [Digital identifiers](/platforms/Emerging/digital-identifiers) and [Data integrity](/platforms/Emerging/data-integrity) as guardrails.
2. **Submit** — Send the proposal through the governance surface your deployment uses (for example on-chain gov module parameters, a **Studio**/**Portal** workflow, or operator-specific APIs—confirm with your program operator). The exact transaction or HTTP call is deployment-specific; align with [Emerging API](/platforms/Emerging/emerging-api) and [Networks and endpoints](/reference/networks-and-endpoints).
3. **Vote** — Token holders, committee members, or allow-listed voters evaluate risk, relayer assignment, and protocol fit. Outcomes are typically **pass**, **fail**, or **abstain** with a quorum threshold.
4. **Execute** — On approval, state transitions run (verification flags, registry pointers, service enablement). On rejection, the domain stays inactive or reverts to the previous version depending on module rules.

For how DAOs fit the wider IXO story, see [DAOs](/articles/daos). For who typically drafts vs votes vs funds programs, see [Your role](/your-role).

## Who does what (roles)

<AccordionGroup>
  <Accordion title="Integration, keys, automation" icon="code">
    * **Typical role:** Developer
    * **Doc entry:** [Your role — Developer](/your-role)
  </Accordion>

  <Accordion title="Evidence review, rubrics, approvals" icon="clipboard-check">
    * **Typical role:** Evaluator
    * **Doc entry:** [Your role — Evaluator](/your-role)
  </Accordion>

  <Accordion title="Capital and outcome-linked funding" icon="hand-holding-dollar">
    * **Typical role:** Funder
    * **Doc entry:** [Your role — Funder](/your-role)
  </Accordion>

  <Accordion title="Implementation and service delivery" icon="handshake">
    * **Typical role:** Service provider
    * **Doc entry:** [Your role — Service provider](/your-role)
  </Accordion>
</AccordionGroup>

## Checklists

**Before submitting a domain proposal**

* Controllers and keys match who will operate the entity on-chain.
* Protocol / class DID is the one your template expects.
* Relayer or service endpoints are reachable from your environment.
* Evidence and metadata align with [Digital certification](/platforms/Emerging/digital-certification) where applicable.

**After vote**

* Poll domain status via GraphQL (see [Query examples](#query-examples) on this page) or your operator dashboard.
* Rotate credentials if the proposal changed controllers or services ([Authentication matrix](/reference/authentication-matrix)).

## Query Examples

### Find Available Protocols

```graphql theme={"system"}
query EntitiesByRelayerNodeAndType {
  entities(
    filter: {
      relayerNode: {equalTo: "did:ixo:entity:a1fcead81eab2f1158a726597d872413"}, 
      type: {equalTo: "protocol"}
    }
  ) {
    nodes {
      id
      type
      metadata
    }
  }
}
```

### Check Domain Status

```graphql theme={"system"}
query DomainStatus($did: String!) {
  entity(id: $did) {
    id
    status
    verificationStatus
    credentials {
      type
      status
    }
  }
}
```

## Implementation Guide

1. [Review available protocols](/platforms/Emerging/registry)
2. [Prepare entity document](/guides/digital-twins)
3. [Submit for verification](/platforms/Emerging/data-integrity)
4. [Configure services](/platforms/Emerging/emerging-api)
5. [Monitor status](/platforms/Emerging/household-monitoring)

## Developer Resources

<CardGroup>
  <Card title="API Reference" icon="code" href="/platforms/Emerging/emerging-api">
    Domain registration endpoints
  </Card>

  <Card title="SDK Guide" icon="box" href="/sdk-reference/index">
    Client libraries and tools
  </Card>

  <Card title="Example Projects" icon="lightbulb" href="/guides/dev/examples">
    Sample implementations
  </Card>

  <Card title="Support" icon="headset" href="https://ixofoundation.slack.com/archives/C04UERAUHQT">
    Developer assistance
  </Card>
</CardGroup>