Skip to main content

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.

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

Organisations

Legal entities managing clean cooking projects

Projects

Mitigation activities and programs

Assets

Physical devices and tokenized outcomes

Protocols

Templates and governance rules

Oracles

AI-enabled verification services

Domain Structure

Core Properties

  • Follows Interchain Identifier methodology
  • Self-sovereign and cryptographically secure
  • Globally unique and resolvable
  • Permanent and immutable
  • Verification credentials
  • Relayer node assignment
  • Validity period
  • Operational status
  • Verification state
  • API endpoints
  • Data streams
  • Oracle integrations
  • Payment services

Registration Process

1. Protocol Selection

Browse Templates

View available protocol templates

Check Requirements

Review domain specifications

Select Protocol

Choose appropriate template

2. Domain Creation

{
  "@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"
}
  • Protocol class reference
  • Entity type specification
  • Relayer node assignment
  • Validity period (optional)
  • Initial status

3. Verification Flow

Submission

Submit domain proposal to DAO

Governance

Community verification voting

Execution

Automatic verification on approval

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 and 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 and 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. For who typically drafts vs votes vs funds programs, see Your role.

Who does what (roles)

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 where applicable.
After vote
  • Poll domain status via GraphQL (see Query examples on this page) or your operator dashboard.
  • Rotate credentials if the proposal changed controllers or services (Authentication matrix).

Query Examples

Find Available Protocols

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

Check Domain Status

query DomainStatus($did: String!) {
  entity(id: $did) {
    id
    status
    verificationStatus
    credentials {
      type
      status
    }
  }
}

Implementation Guide

  1. Review available protocols
  2. Prepare entity document
  3. Submit for verification
  4. Configure services
  5. Monitor status

Developer Resources

API Reference

Domain registration endpoints

SDK Guide

Client libraries and tools

Example Projects

Sample implementations

Support

Developer assistance