DEV Community: Michael Kantor

Trust Before Install: Why We Built Codex Plugin Scanner

Michael Kantor — Thu, 02 Apr 2026 03:06:11 +0000

Originally published at https://hol.org/blog/trust-before-install-why-we-built-codex-plugin-scanner

Codex plugins can do real work.

They can package skills, connect apps, expose MCP servers, and extend what Codex can access or automate. That makes them powerful. It also means they introduce a new trust surface.

A plugin is not just a manifest file. It can include remote endpoints, local commands, repository workflows, install metadata, marketplace metadata, and reusable skills that influence behavior. Runtime safeguards still matter, but they are only part of the story. Teams also need a way to evaluate plugin quality and risk before a plugin gets installed, shared, or listed publicly.

That is why we built Codex Plugin Scanner.

It is an open-source scanner for Codex plugins that checks security, publishability, MCP risk, workflow hygiene, and overall ecosystem readiness. The goal is simple: make it easier to understand whether a plugin is safe and well-structured before it spreads.

The problem

Most existing security tooling was not built for this ecosystem.

A linter can catch syntax issues. A secret scanner can catch some exposed credentials. A dependency scanner can point out vulnerable packages. Those tools are useful, but they do not answer the main questions plugin authors, reviewers, and registries actually have:

Is this plugin manifest valid and publishable?
Are its declared paths safe?
Does it point to risky MCP endpoints?
Does it normalize unsafe approval patterns?
Does it ship repository automation that introduces supply-chain risk?
Is it ready for listing in a broader plugin ecosystem?

That gap gets bigger as the ecosystem grows.

What Codex Plugin Scanner does

Codex Plugin Scanner was built specifically for Codex plugins. It scores the applicable plugin surface from 0 to 100, produces structured findings, and helps maintainers catch issues before release.

The scanner evaluates plugins across several categories:

1. Manifest validation

It checks whether the plugin manifest exists, parses correctly, includes required fields, uses semantic versioning, and contains the metadata needed for distribution.

It also validates interface metadata, verifies assets and links, and checks that referenced paths stay inside the repository.

2. Security

It looks for common security problems such as:

hardcoded secrets
dangerous MCP command patterns
insecure remote MCP transports
approval bypass defaults
shell injection patterns
unsafe dynamic execution patterns like eval()

3. Operational security

This is one of the most useful parts of the scanner.

A plugin does not just ship code. It often ships automation. The scanner checks GitHub workflows for issues like:

third-party actions that are not pinned to full SHAs
overly broad workflow permissions
unsafe checkout patterns
missing dependency update automation
missing lockfiles or weak dependency pinning

That helps teams catch supply-chain issues that are easy to miss in a basic plugin review.

4. Best practices

The scanner also checks for project hygiene, including:

README.md
LICENSE
SECURITY.md
.codexignore
committed .env files
missing skills directories
malformed SKILL.md frontmatter

5. Marketplace and ecosystem readiness

If a plugin includes marketplace metadata, the scanner validates that too. This makes it easier to assess whether a plugin is ready to be listed, shared, or ingested into registries and discovery surfaces.

6. Skill security

When skills are present, the scanner can perform deeper analysis. It also supports optional Cisco-backed skill analysis for teams that want an additional review layer.

Why the scoring model matters

We did not want a score that was noisy or misleading.

A lot of scanners treat every possible surface as mandatory. That creates bad results. A small plugin gets penalized for not shipping marketplace metadata. A simple skills package gets scored as incomplete because it does not expose MCP configuration.

That does not reflect reality.

Codex Plugin Scanner only scores the surfaces that actually apply to the plugin being scanned. If a plugin does not include .mcp.json, it is not penalized for that. If it does not use marketplace metadata, those checks are not counted against it.

That makes the final score much more useful across different plugin types.

Built for real workflows

The scanner is designed to fit into the workflows teams already use.

You can run it locally during development, wire it into CI, use it in pre-commit, or export results into GitHub code scanning.

It supports multiple output formats, including:

text
JSON
Markdown
SARIF

A typical run looks like this:

pip install codex-plugin-scanner
codex-plugin-scanner ./my-plugin \
  --format sarif \
  --output codex-plugin-scanner.sarif \
  --fail-on-severity high

That makes it straightforward to use as a local quality gate or as part of an automated release process.

More than a scanner

One thing we cared about from the start was making the output useful beyond a terminal window.

The GitHub Action can export a machine-readable payload with metadata such as plugin name, description, score, grade, severity counts, source repository, source SHA, scanner version, and timestamp.

That opens the door to things like:

plugin registry ingestion
automated badges
awesome-list submissions
ecosystem dashboards
CI trust gates

In other words, the scanner is not just for maintainers. It can also become part of the broader trust infrastructure around the plugin ecosystem.

What this means for the ecosystem

We think the Codex plugin ecosystem needs a trust layer.

As more people build and publish plugins, the challenge is no longer just creating functionality. It is helping users and reviewers understand what they are installing and whether it meets a reasonable standard for safety and quality.

That does not mean one score should replace human judgment. It should not.

What it should do is make the obvious problems easier to catch, make reviews more consistent, and give teams a common baseline for plugin quality.

That is the role Codex Plugin Scanner is meant to play.

Why we built it

We built Codex Plugin Scanner because trust should not be an afterthought.

If plugins are going to become a serious part of how developers and teams extend Codex, then the ecosystem needs tooling that is built for that exact surface area. Not generic security theater. Not a checklist copied from somewhere else. Something purpose-built.

That is what this project is.

It is an open-source scanner for a new plugin ecosystem that needs better safety, clearer standards, and better distribution hygiene from day one.

Get involved

If you are building Codex plugins, maintaining a registry, or thinking about trust and distribution in this ecosystem, take a look at the project and try it on your own repositories.

Repo: https://github.com/hashgraph-online/codex-plugin-scanner

We think the ecosystem will be healthier if plugin quality is easier to measure, easier to improve, and easier to trust.

E2E Test Scheduled Post

Michael Kantor — Sat, 14 Mar 2026 12:56:54 +0000

Originally published at https://hol.org/blog/e2e-test-post-64edb6d6-8c05-4ed6-afbf-1f6f766190dd

This is an E2E test to verify that the scheduled publishing cron task triggers effectively and publishes a post that was written in the past.

Building End-to-End Encrypted Agent Conversations with Registry Broker

Michael Kantor — Wed, 04 Mar 2026 12:49:07 +0000

Agents handle secrets: API keys, medical records, financial data. TLS protects these in transit, but it leaves them exposed on the server.

End-to-end encryption (E2EE) fixes this. Messages are encrypted at the source and decrypted only at the destination. The Registry Broker stores the message, but it can't read it.

Only the sender and recipient hold the keys.

Understanding E2EE in the Agent Context

Standard client-server encryption places trust in the server. For agents, this is a vulnerability:

Data exposure: Intermediaries log everything.
Compliance: GDPR and HIPAA often require you to remove the platform from the trust boundary.
Audit trails: Even if the message body is private, metadata leaks intent.

E2EE removes the platform from the equation. The Registry Broker becomes a dumb pipe for encrypted envelopes.

The Encryption Architecture

The Registry Broker's E2EE implementation uses:

Long-term identity keys: Each agent registers a persistent public key
Ephemeral session keys: Fresh keys generated for each conversation
X3DH-style handshake: A key agreement protocol that establishes shared secrets
AES-GCM encryption: Industry-standard symmetric encryption for messages

The flow works as follows:

Agent A                    Registry Broker                    Agent B
   |                            |                                |
   |---- Register Public Key -->|<--- Register Public Key ------|
   |                            |                                |
   |---- Start Session -------->|                                |
   |<--- Handshake Record ------|                                |
   |                            |---- Notify Session ----------->|
   |                            |<--- Complete Handshake -------|
   |                            |                                |
   |---- Encrypted Message ---->|---- Forward Ciphertext ------>|
   |                            |                                |

Prerequisites

Install the required packages:

npm install @hashgraphonline/standards-sdk dotenv

Configure your environment:

# .env
REGISTRY_BROKER_BASE_URL=https://hol.org/registry/api/v1
HEDERA_ACCOUNT_ID=0.0.12345
HEDERA_PRIVATE_KEY=302e...

Step 1: Initializing Agents with Encryption Keys

The first step is to initialize each agent with encryption capabilities. The RegistryBrokerClient.initializeAgent static method handles key generation and registration:


const brokerUrl = process.env.REGISTRY_BROKER_BASE_URL 
  ?? 'https://hol.org/registry/api/v1';

// First, create an admin client for registration
const adminClient = new RegistryBrokerClient({ baseUrl: brokerUrl });

// Authenticate if needed (for credit-based operations)
await adminClient.authenticateWithLedgerCredentials({
  accountId: process.env.HEDERA_ACCOUNT_ID!,
  network: `hedera:${process.env.HEDERA_NETWORK ?? 'testnet'}`,
  hederaPrivateKey: process.env.HEDERA_PRIVATE_KEY!,
  expiresInMinutes: 60,
  label: 'e2ee-demo',
});

// Get shared headers for child clients
const sharedHeaders = adminClient.getDefaultHeaders();

// Initialize Agent A with encryption
const agentASetup = await RegistryBrokerClient.initializeAgent({
  baseUrl: brokerUrl,
  defaultHeaders: sharedHeaders,
  uaid: agentAUaid,
  encryption: { 
    autoDecryptHistory: true 
  },
  ensureEncryptionKey: {
    uaid: agentAUaid,
    generateIfMissing: true,
    label: 'agent-a-encryption-key',
  },
});

console.log(`Agent A initialized with encryption key`);
const agentAClient = agentASetup.client;

// Initialize Agent B similarly
const agentBSetup = await RegistryBrokerClient.initializeAgent({
  baseUrl: brokerUrl,
  defaultHeaders: sharedHeaders,
  uaid: agentBUaid,
  encryption: { 
    autoDecryptHistory: true 
  },
  ensureEncryptionKey: {
    uaid: agentBUaid,
    generateIfMissing: true,
    label: 'agent-b-encryption-key',
  },
});

console.log(`Agent B initialized with encryption key`);
const agentBClient = agentBSetup.client;

The ensureEncryptionKey option tells the SDK to:

Check if a long-term encryption key already exists for this UAID
If not, generate a new key pair
Register the public key with the Registry Broker
Store the private key securely in the client instance

Step 2: Starting an Encrypted Conversation

Agent A (the requester) initiates the conversation using startConversation with encryption preferences:

// Agent A starts the conversation with encryption required
let sessionId: string | undefined;

const agentAConversation = await agentAClient.chat.startConversation({
  uaid: agentBUaid,
  senderUaid: agentAUaid,
  encryption: { 
    preference: 'required' // Options: 'required', 'preferred', 'disabled'
  },
  onSessionCreated: (id) => {
    sessionId = id;
    console.log(`Session created: ${id}`);
  },
});

console.log(`Conversation mode: ${agentAConversation.mode}`);
console.log(`Encryption algorithm: ${agentAConversation.summary?.algorithm ?? 'none'}`);

The preference option controls encryption behavior:

required: Fail if encryption cannot be established
preferred: Use encryption if available, fall back to plaintext
disabled: Always use plaintext (transport encryption only)

Step 3: Accepting the Encrypted Session

Agent B (the responder) must accept the conversation and complete the handshake:

// Agent B accepts the encrypted conversation
// In production, you'd receive the sessionId via a notification mechanism
const agentBConversation = await agentBClient.chat.acceptConversation({
  sessionId: sessionId!,
  responderUaid: agentBUaid,
  encryption: { 
    preference: 'required' 
  },
});

console.log(`Agent B joined session with mode: ${agentBConversation.mode}`);

Once both agents have completed the handshake, they share a symmetric key that only they know. The Registry Broker has the encrypted handshake records but cannot derive the shared secret.

Step 4: Sending Encrypted Messages

Sending encrypted messages uses the conversation handle's send method. The SDK handles all encryption transparently:

// Agent A sends an encrypted message
await agentAConversation.send({
  plaintext: 'Hello from Agent A! This message is encrypted end-to-end.',
});

console.log('Agent A sent encrypted message');

// Agent B sends a reply
await agentBConversation.send({
  plaintext: 'Agent B received your message. Replying with sensitive data: SSN-123-45-6789',
});

console.log('Agent B sent encrypted reply');

Behind the scenes, the SDK:

Encrypts the plaintext using AES-GCM with the shared session key
Packages the ciphertext into an envelope with metadata
Sends the envelope to the Registry Broker's /chat/message endpoint
The broker stores only the encrypted envelope

Step 5: Retrieving and Decrypting History

Both agents can retrieve and decrypt the conversation history:

// Agent A retrieves history
const agentAHistory = await agentAClient.chat.getHistory(
  agentAConversation.sessionId,
  { decrypt: true }
);

console.log(`\nAgent A's decrypted view:`);
for (const entry of agentAHistory.decryptedHistory ?? []) {
  console.log(`  [${entry.role}] ${entry.plaintext}`);
}

// Agent B retrieves the same history
const agentBHistory = await agentBClient.chat.getHistory(
  agentBConversation.sessionId,
  { decrypt: true }
);

console.log(`\nAgent B's decrypted view:`);
for (const entry of agentBHistory.decryptedHistory ?? []) {
  console.log(`  [${entry.role}] ${entry.plaintext}`);
}

The { decrypt: true } option tells the SDK to use the stored session keys to decrypt each message. Both agents see the same plaintext because they share the same session key.

Step 6: Complete Working Example

Here's a complete example bringing it all together:

import 'dotenv/config';

async function runEncryptedChatDemo(): Promise<void> {
  const brokerUrl = process.env.REGISTRY_BROKER_BASE_URL 
    ?? 'https://hol.org/registry/api/v1';

  // Assume we have two registered agents with these UAIDs
  const agentAUaid = process.env.AGENT_A_UAID!;
  const agentBUaid = process.env.AGENT_B_UAID!;

  // Create admin client for authentication
  const adminClient = new RegistryBrokerClient({ baseUrl: brokerUrl });

  // Authenticate with Hedera credentials
  await adminClient.authenticateWithLedgerCredentials({
    accountId: process.env.HEDERA_ACCOUNT_ID!,
    network: `hedera:testnet`,
    hederaPrivateKey: process.env.HEDERA_PRIVATE_KEY!,
    expiresInMinutes: 60,
    label: 'e2ee-complete-demo',
  });

  const headers = adminClient.getDefaultHeaders();

  // Initialize both agents with encryption
  console.log('🔐 Initializing agents with encryption...');

  const [agentASetup, agentBSetup] = await Promise.all([
    RegistryBrokerClient.initializeAgent({
      baseUrl: brokerUrl,
      defaultHeaders: headers,
      uaid: agentAUaid,
      encryption: { autoDecryptHistory: true },
      ensureEncryptionKey: {
        uaid: agentAUaid,
        generateIfMissing: true,
        label: 'demo-agent-a',
      },
    }),
    RegistryBrokerClient.initializeAgent({
      baseUrl: brokerUrl,
      defaultHeaders: headers,
      uaid: agentBUaid,
      encryption: { autoDecryptHistory: true },
      ensureEncryptionKey: {
        uaid: agentBUaid,
        generateIfMissing: true,
        label: 'demo-agent-b',
      },
    }),
  ]);

  const agentAClient = agentASetup.client;
  const agentBClient = agentBSetup.client;

  // Coordinate the conversation start
  let resolveSessionId: (id: string) => void;
  const sessionIdReady = new Promise<string>(r => { resolveSessionId = r; });

  console.log('🤝 Establishing encrypted session...');

  // Agent A starts, Agent B waits for session ID
  const [conversationA, conversationB] = await Promise.all([
    agentAClient.chat.startConversation({
      uaid: agentBUaid,
      senderUaid: agentAUaid,
      encryption: { preference: 'required' },
      onSessionCreated: id => {
        console.log(`  📬 Session: ${id}`);
        resolveSessionId!(id);
      },
    }),
    sessionIdReady.then(sessionId =>
      agentBClient.chat.acceptConversation({
        sessionId,
        responderUaid: agentBUaid,
        encryption: { preference: 'required' },
      })
    ),
  ]);

  console.log(`✅ Encrypted session established (${conversationA.summary?.algorithm})`);

  // Exchange messages
  console.log('\n📨 Exchanging encrypted messages...');

  await conversationA.send({ 
    plaintext: 'Confidential: Q4 revenue projections attached.' 
  });
  console.log('  Agent A: sent encrypted message');

  await conversationB.send({ 
    plaintext: 'Received. Forwarding to CFO with encryption intact.' 
  });
  console.log('  Agent B: sent encrypted reply');

  // Verify both can decrypt
  console.log('\n🔓 Verifying decryption...');

  const historyA = await agentAClient.chat.getHistory(
    conversationA.sessionId, 
    { decrypt: true }
  );

  console.log('Agent A sees:');
  for (const msg of historyA.decryptedHistory ?? []) {
    console.log(`  [${msg.role}]: ${msg.plaintext}`);
  }

  console.log('\n✅ E2EE demo complete');
}

runEncryptedChatDemo().catch(console.error);

Security Best Practices

When implementing E2EE agent communication:

Protect private keys: Store encryption keys securely, never in logs or configs
Rotate keys periodically: Generate new long-term keys on a schedule
Verify identities: Confirm UAIDs before establishing encrypted sessions
Handle failures gracefully: Have fallback behavior when encryption fails
Audit metadata: Even with E2EE, connection patterns are visible

When to Use E2EE

Use end-to-end encryption when:

Handling personally identifiable information (PII)
Processing financial or healthcare data
Complying with privacy regulations
Communicating across organizational boundaries
The communication content is more sensitive than the metadata

For less sensitive use cases, the transport-layer encryption (TLS) provided by default may be sufficient.

Conclusion

End-to-end encryption turns the Registry Broker into a zero-knowledge relay. It handles the connection and stores the encrypted data, but it never sees the content.

This is the only way to build compliant AI systems that handle sensitive user data.

Building Always-On AI Agents: From Passive Chatbots to Autonomous Services

Michael Kantor — Wed, 04 Mar 2026 12:48:34 +0000

Most agent tutorials build simple chatbots: send message, get response. This works for demos, but production infrastructure needs to run autonomously.

Service Agents are long-running processes that monitor data and take action without human input. They don't wait for prompts; they wait for events.

In this guide, we'll architect a production-ready service agent using the Registry Broker's session management and polling capabilities.

Understanding Agent Lifecycle Models

Before building, let's understand the fundamental difference between agent architectures:

Request-Response Agents

Wake up when called
Process one request
Return a response
Effectively "die" until the next request

This is how most web APIs work—stateless, ephemeral, horizontal-scalable but fundamentally passive.

Service Agents (Always-On)

Boot once and run indefinitely
Maintain persistent state
Monitor for events continuously
React autonomously to triggers

Service agents act more like database servers or message brokers than web handlers. They require different architectural thinking.

The Core Pattern: Event Loop with Polling

The Registry Broker doesn't provide push notifications for new messages (WebSocket subscriptions are for real-time chat, not general event streaming). Instead, service agents use a polling pattern to check for new activity.

Here's the foundational structure:

import { 
  RegistryBrokerClient,
  type ChatHistoryEntry 
} from '@hashgraphonline/standards-sdk';

interface SessionState {
  lastChecked: number;
  messageCount: number;
}

class ServiceAgent {
  private client: RegistryBrokerClient;
  private myUaid: string;
  private activeSessions: Map<string, SessionState> = new Map();
  private running: boolean = false;

  constructor(uaid: string, brokerUrl: string) {
    this.myUaid = uaid;
    this.client = new RegistryBrokerClient({ baseUrl: brokerUrl });
  }

  async start(): Promise<void> {
    console.log(`Service agent starting: ${this.myUaid}`);
    console.log(`Online at ${new Date().toISOString()}`);

    this.running = true;

    while (this.running) {
      try {
        await this.pollActiveSessions();
      } catch (error) {
        console.error('Polling error:', error);
        // Continue running despite errors
      }

      // Wait before next poll cycle
      await this.delay(2000);
    }
  }

  stop(): void {
    console.log('Service agent shutting down...');
    this.running = false;
  }

  private async pollActiveSessions(): Promise<void> {
    for (const [sessionId, state] of this.activeSessions) {
      const history = await this.client.chat.getHistory(sessionId);
      const allMessages = history.history ?? [];

      // Find messages newer than our last check
      const newMessages = allMessages.filter(
        entry => new Date(entry.timestamp).getTime() > state.lastChecked
      );

      // Process only user messages (we sent the agent ones)
      const userMessages = newMessages.filter(m => m.role === 'user');

      for (const message of userMessages) {
        await this.handleMessage(sessionId, message);
      }

      // Update state
      state.lastChecked = Date.now();
      state.messageCount = allMessages.length;
    }
  }

  async handleMessage(
    sessionId: string, 
    message: ChatHistoryEntry
  ): Promise<void> {
    // Override this in subclasses for custom behavior
    console.log(`New message in ${sessionId}: ${message.content}`);
  }

  registerSession(sessionId: string): void {
    if (!this.activeSessions.has(sessionId)) {
      this.activeSessions.set(sessionId, {
        lastChecked: Date.now(),
        messageCount: 0,
      });
      console.log(`Tracking session: ${sessionId}`);
    }
  }

  private delay(ms: number): Promise<void> {
    return new Promise(resolve => setTimeout(resolve, ms));
  }
}

This base class provides the event loop infrastructure. Subclass it to add domain-specific behavior.

Example: The Sentinel Agent

Let's build a "Sentinel" agent that monitors for critical alerts and triggers external systems:

class SentinelAgent extends ServiceAgent {
  private alertThreshold: number;

  constructor(
    uaid: string, 
    brokerUrl: string, 
    alertThreshold: number = 5
  ) {
    super(uaid, brokerUrl);
    this.alertThreshold = alertThreshold;
  }

  async handleMessage(
    sessionId: string,
    message: ChatHistoryEntry
  ): Promise<void> {
    const content = message.content.toUpperCase();

    console.log(`[SENTINEL] Analyzing: ${content.substring(0, 50)}...`);

    // Pattern matching for critical signals
    if (this.isCriticalSignal(content)) {
      console.warn('>>> CRITICAL SIGNAL DETECTED');
      await this.triggerEmergencyProtocol(sessionId, content);
    } else if (this.isRoutineCheck(content)) {
      await this.acknowledgeRoutine(sessionId);
    }
  }

  private isCriticalSignal(content: string): boolean {
    const criticalPatterns = [
      'CRITICAL_FAILURE',
      'SECURITY_BREACH',
      'PRICE_DUMP',
      'SYSTEM_DOWN',
      'UNAUTHORIZED_ACCESS',
    ];
    return criticalPatterns.some(pattern => content.includes(pattern));
  }

  private isRoutineCheck(content: string): boolean {
    return content.includes('STATUS') || content.includes('HEALTH_CHECK');
  }

  private async triggerEmergencyProtocol(
    sessionId: string,
    content: string
  ): Promise<void> {
    // 1. Log the incident
    console.log(`Emergency triggered at ${new Date().toISOString()}`);
    console.log(`Content: ${content}`);

    // 2. Call external alerting system
    await this.notifyPagerDuty(content);

    // 3. Send acknowledgment through the broker
    await this.client.chat.sendMessage({
      sessionId: sessionId,
      message: 'ACK. Emergency protocols initiated. On-call team summoned.',
    });
  }

  private async acknowledgeRoutine(sessionId: string): Promise<void> {
    const status = {
      status: 'healthy',
      uptime: process.uptime(),
      timestamp: new Date().toISOString(),
      activeSessions: this.activeSessions.size,
    };

    await this.client.chat.sendMessage({
      sessionId,
      message: `Status report: ${JSON.stringify(status)}`,
    });
  }

  private async notifyPagerDuty(content: string): Promise<void> {
    // In production, integrate with your actual alerting system
    console.log(`[PAGERDUTY] Sending alert: ${content.substring(0, 100)}`);

    // Example: fetch('https://events.pagerduty.com/v2/enqueue', { ... })
  }
}

Running the Service Agent

Deploy the agent as a long-running process:

import 'dotenv/config';

async function main() {
  const agent = new SentinelAgent(
    process.env.AGENT_UAID!,
    process.env.REGISTRY_BROKER_BASE_URL ?? 'https://hol.org/registry/api/v1',
  );

  // Register sessions to monitor
  // In practice, these come from your session management layer
  const sessionsToMonitor = process.env.MONITOR_SESSIONS?.split(',') ?? [];
  for (const sessionId of sessionsToMonitor) {
    agent.registerSession(sessionId.trim());
  }

  // Handle shutdown gracefully
  process.on('SIGTERM', () => agent.stop());
  process.on('SIGINT', () => agent.stop());

  // Start the event loop
  await agent.start();
}

main().catch(console.error);

Production Deployment Considerations

Containerization

Service agents should run in containers for reliability:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist ./dist
CMD ["node", "dist/sentinel.js"]

Scaling

Because the Registry Broker maintains session state, you can run multiple agent instances:

Session sharding: Different instances monitor different session ranges
Leader election: Use Redis or etcd to elect a primary instance
Stateless processing: Each poll is independent, enabling horizontal scaling

Monitoring

Add observability to your agent:

// Emit metrics
setInterval(() => {
  console.log(JSON.stringify({
    type: 'agent_metrics',
    activeSessions: activeSessions.size,
    uptimeSeconds: process.uptime(),
    memoryMB: process.memoryUsage().heapUsed / 1024 / 1024,
    timestamp: new Date().toISOString(),
  }));
}, 60000);

Error Recovery

Service agents must handle failures gracefully:

async pollWithRetry(sessionId: string, retries: number = 3): Promise<void> {
  for (let attempt = 0; attempt < retries; attempt++) {
    try {
      return await this.pollSession(sessionId);
    } catch (error) {
      console.warn(`Poll attempt ${attempt + 1} failed:`, error);
      await this.delay(1000 * (attempt + 1)); // Exponential backoff
    }
  }
  console.error(`Session ${sessionId} unreachable after ${retries} attempts`);
}

Use Cases for Service Agents

DeFi Liquidation Bot

Monitors price feeds from oracles
Detects undercollateralized positions
Executes liquidation transactions automatically

Customer Support Triage

Listens to incoming support conversations
Classifies urgency using an LLM
Routes to appropriate human agents
Handles simple queries autonomously

Security Monitor

Analyzes logs from other agents
Detects anomalous patterns
Triggers lockdown procedures
Generates incident reports

Workflow Orchestrator

Monitors for task completion signals
Triggers next steps in pipelines
Handles retries and failures
Maintains workflow state

From Chatbot to Infrastructure

Passive chatbots answer questions when asked. Service agents are infrastructure—they run continuously, monitor actively, and act autonomously. Moving from request-response to event-loop processing enables a new class of AI applications.

The Registry Broker handles the session management and message routing. Your agent provides the intelligence. Together, they create autonomous systems.

ERC-8004: Building Trustless AI Agent Identity on the Blockchain

Michael Kantor — Wed, 04 Mar 2026 12:48:01 +0000

On the internet, nobody knows you're a dog. In the agent economy, nobody knows if you're a scammer.

When agents start moving real money—managing portfolios, buying APIs, signing contracts—trust is the bottleneck. You need answers: Who owns this thing? What's its track record? Is it running the code it claims?

ERC-8004 proposes a standard for Trustless Agent Identity. It moves reputation out of centralized databases and onto immutable EVM ledgers.

The Registry Broker supports this standard today. It lets agents carry verifiable "on-chain business cards" alongside their fast HCS-10 comms channels.

Why On-Chain Identity Matters

As AI agents take on more responsibility, developers need stronger guarantees about identity and trust:

Cryptographic Provenance

Traditional agent profiles are valuable for discovery, but on-chain registration adds cryptographic proof. You can mathematically verify who controls an agent.

Immutable Reputation

On-chain reputation systems create permanent, auditable records. Historical performance data can be verified by anyone and cannot be retroactively modified.

Code Integrity Verification

For high-stakes applications, knowing that an agent runs audited, unmodified code is essential. On-chain attestations provide this assurance.

The ERC-8004 Solution

ERC-8004 addresses these problems through three on-chain registries:

1. Identity Registry (The Owner)

A smart contract maps agent IDs to wallet addresses. To register, you sign a message.

This gives you:

Provenance: Mathematical proof of creation
Recoverability: Standard key rotation patterns
Corporate Control: Multi-sig wallets can own agents

2. Reputation Registry (Are You Good?)

The Reputation Registry stores on-chain feedback and ratings. Key properties:

Reviews cost gas: Submitting feedback requires a transaction fee, reducing spam
Reviews are signed: Every rating is linked to a real wallet with history
Reviews are immutable: Historical reputation cannot be edited or deleted
Aggregation is transparent: Anyone can verify the reputation calculation

3. Validation Registry (Is Your Code Safe?)

The Validation Registry stores attestations about agent code integrity:

Code hashes: Cryptographic fingerprints of audited agent code
TEE attestations: Proofs that the agent runs in a Trusted Execution Environment
Audit records: Links to security audits and their findings
Version tracking: History of code changes and their attestations

The Dual-Identity Architecture

Blockchains provide immutability, while protocols like HCS-10 provide speed. The dual-identity architecture combines both:

Layer	Technology	Purpose	Speed
Fast Layer	HCS-10 (Hedera)	Messaging, real-time chat	Milliseconds
Hard Layer	ERC-8004 (Base)	Identity, reputation	Block time

Agents maintain identity on both layers:

HCS-10 UAID: For discovering, addressing, and messaging the agent
ERC-8004 Registration: For verifying ownership and checking reputation

The Registry Broker links these identities, allowing clients to verify on-chain credentials before initiating fast-layer communication.

Implementation: Registering a Dual-Identity Agent

Here's how to register an agent with both HCS-10 and ERC-8004 identity:

Step 1: Register on the Fast Layer

import { 
  RegistryBrokerClient,
  ProfileType,
  AIAgentType,
  AIAgentCapability,
} from '@hashgraphonline/standards-sdk';

const client = new RegistryBrokerClient({ 
  baseUrl: 'https://hol.org/registry/api/v1' 
});

// Authenticate with Hedera credentials
await client.authenticateWithLedgerCredentials({
  accountId: process.env.HEDERA_ACCOUNT_ID!,
  network: 'hedera:testnet',
  hederaPrivateKey: process.env.HEDERA_PRIVATE_KEY!,
  expiresInMinutes: 60,
  label: 'dual-identity-demo',
});

// Register the agent with HCS-10 identity
const registration = await client.registerAgent({
  profile: {
    type: ProfileType.AI_AGENT,
    version: '1.0',
    display_name: 'Trustless DeFi Advisor',
    alias: 'defi-advisor-alpha',
    bio: 'Autonomous DeFi portfolio management with on-chain verified identity and audited decision logic.',
    aiAgent: {
      type: AIAgentType.AUTONOMOUS,
      model: 'gpt-4-turbo',
      capabilities: [
        AIAgentCapability.TEXT_GENERATION,
        AIAgentCapability.DATA_ANALYSIS,
      ],
    },
  },
  communicationProtocol: 'a2a',
  registry: 'hashgraph-online',
});

console.log(`Fast-layer identity established: ${registration.uaid}`);

Step 2: Link the Hard Layer Identity

After registering, link the ERC-8004 on-chain identity:

// Update registration to include ERC-8004 anchor
await client.updateAgent(registration.uaid!, {
  profile: registration.profile,
  communicationProtocol: 'a2a',
  registry: 'hashgraph-online',
  // Add the on-chain identity anchor
  additionalRegistries: ['erc-8004:base-sepolia'],
  metadata: {
    // Link to the controlling wallet
    ownerWallet: '0x1234...abcd',
    // Reference to code audit
    auditUrl: 'https://audits.myorg.com/defi-advisor-v1.pdf',
    // TEE attestation (if running in secure enclave)
    teeAttestation: 'attestation-hash-here',
  },
});

console.log('Hard-layer identity linked');

The broker validates ownership of the linked wallet before accepting the update, preventing unauthorized identity claims.

Discovering Verified Agents

Clients can search specifically for agents with on-chain verification:

async function findVerifiedAgents(query: string): Promise<void> {
  const results = await client.search({
    registries: ['erc-8004-adapter'],
    q: query,
    limit: 20,
  });

  console.log(`Found ${results.total} ERC-8004 verified agents:`);

  for (const agent of results.hits) {
    console.log(`\n${agent.name}`);
    console.log(`  UAID: ${agent.uaid}`);

    // Access ERC-8004 specific metadata
    const metadata = agent.metadata;
    if (metadata) {
      console.log(`  Chain: ${metadata.chainName ?? 'unknown'}`);
      console.log(`  Owner: ${metadata.ownerWallet ?? 'not disclosed'}`);
      console.log(`  Verified: ${metadata.verified ?? false}`);

      // Reputation data from on-chain registry
      if (metadata.reputation) {
        const rep = metadata.reputation as Record<string, unknown>;
        console.log(`  Rating: ${rep.averageScore ?? 'N/A'}/5`);
        console.log(`  Reviews: ${rep.totalReviews ?? 0}`);
      }
    }
  }
}

// Find verified trading advisors
await findVerifiedAgents('trading advisor');

Filtering by Chain and Verification Status

// Search for agents verified on specific chains
const baseAgents = await client.search({
  registries: ['erc-8004-adapter'],
  q: 'portfolio management',
  metadata: {
    'chainName': ['Base Sepolia', 'Base'],
  },
  verified: true,
});

console.log(`Found ${baseAgents.hits.length} verified agents on Base`);

Verifying Agent Identity On-Chain

For high-stakes interactions, clients should verify identity directly on-chain:



// The ERC-8004 Identity Registry contract
const IDENTITY_REGISTRY = '0x...'; // Contract address

const publicClient = createPublicClient({
  chain: baseSepolia,
  transport: http(),
});

async function verifyAgentOwnership(
  agentId: string,
  expectedOwner: string
): Promise<boolean> {
  const owner = await publicClient.readContract({
    address: IDENTITY_REGISTRY as `0x${string}`,
    abi: identityRegistryAbi,
    functionName: 'ownerOf',
    args: [agentId],
  });

  return owner.toLowerCase() === expectedOwner.toLowerCase();
}

async function getAgentReputation(agentId: string): Promise<{
  score: number;
  reviewCount: number;
}> {
  const reputation = await publicClient.readContract({
    address: IDENTITY_REGISTRY as `0x${string}`,
    abi: reputationRegistryAbi,
    functionName: 'getReputation',
    args: [agentId],
  });

  return {
    score: Number(reputation.averageScore) / 100, // Stored as integer
    reviewCount: Number(reputation.totalReviews),
  };
}

Use Cases for ERC-8004

Autonomous Fund Management

DeFi protocols can verify that an agent managing user funds has:

A known, auditable owner
Positive historical reputation
Code running in a verified TEE

Agent-to-Agent Commerce

When one agent hires another for a task:

Verify the service provider's identity on-chain
Check reputation before sending payment
Maintain an immutable record of the transaction

Regulated Industries

For agents operating in regulated spaces (finance, healthcare):

Link agent identity to licensed entities
Maintain auditable reputation history
Provide regulators with verifiable chain of custody

Insurance and Liability

Agent insurance providers can:

Assess risk based on on-chain reputation
Verify code integrity before issuing coverage
Track claims against specific agents immutably

Building Trust

ERC-8004 changes the trust model. We're moving from "trust the platform" to "verify the chain."

Combining Hedera's speed with EVM immutability creates a robust infrastructure for autonomous commerce.

You can send funds to an agent knowing exactly who controls it. You can verify its reputation score without asking a central API. This is what's required for the autonomous economy.

Discovering MIT NANDA Agents with Registry Broker

Michael Kantor — Wed, 04 Mar 2026 12:47:29 +0000

NANDA (Networked Agents and Decentralized AI) creates infrastructure for decentralized agents. It builds on protocols like MCP and A2A to handle agent identification and routing.

The Hashgraph Online Registry Broker now includes a NANDA Adapter. This lets you discover and talk to NANDA agents using the same API you use for everything else.

Understanding NANDA

NANDA addresses fundamental questions for autonomous agent systems:

How do agents find each other? A decentralized registry provides discoverability without centralized control
How do agents establish trust? Verifiable attestations and reputation mechanisms
How do agents communicate? Standardized protocols including A2A (Agent-to-Agent) messaging
How does the ecosystem scale? Open, extensible architecture supporting diverse agent types

The NANDA framework complements other agent ecosystems like AgentVerse, Virtuals, and MCP by providing a research-oriented, academically-rigorous approach to agent infrastructure.

Prerequisites

Install the standards SDK:

npm install @hashgraphonline/standards-sdk dotenv

Configure your environment:

# .env
REGISTRY_BROKER_BASE_URL=https://hol.org/registry/api/v1

Discovering NANDA Agents

Search for agents registered in the NANDA ecosystem:


const client = new RegistryBrokerClient({ 
  baseUrl: process.env.REGISTRY_BROKER_BASE_URL 
    ?? 'https://hol.org/registry/api/v1' 
});

async function discoverNandaAgents(): Promise<void> {
  const results = await client.search({
    registries: ['nanda'],
    limit: 10,
  });

  console.log(`Found ${results.total} NANDA agents:`);

  for (const agent of results.hits) {
    console.log(`\n${agent.name}`);
    console.log(`  UAID: ${agent.uaid}`);
    console.log(`  Available: ${agent.available ?? 'unknown'}`);

    // Check for A2A endpoint
    const endpoints = agent.endpoints as Record<string, unknown> | undefined;
    if (endpoints) {
      const a2aEndpoint = extractA2aEndpoint(endpoints);
      if (a2aEndpoint) {
        console.log(`  A2A Endpoint: ${a2aEndpoint}`);
      }
    }
  }
}

function extractA2aEndpoint(
  endpoints: Record<string, unknown>
): string | undefined {
  // Check custom endpoints first
  const custom = endpoints.customEndpoints as Record<string, unknown> | undefined;
  if (custom?.a2a && typeof custom.a2a === 'string') {
    return custom.a2a;
  }

  // Fall back to primary endpoint
  if (typeof endpoints.api === 'string') {
    return endpoints.api;
  }

  return undefined;
}

Communicating with NANDA Agents

NANDA agents support the A2A (Agent-to-Agent) protocol. The Registry Broker handles protocol translation, allowing you to use the standard chat API:

async function chatWithNandaAgent(uaid: string): Promise<void> {
  console.log(`Starting conversation with NANDA agent: ${uaid}`);

  // Send a message through the broker
  const response = await client.chat.sendMessage({
    uaid,
    message: 'Hello! What capabilities do you have?',
  });

  console.log(`Response: ${response.message}`);
  console.log(`Session: ${response.sessionId}`);

  // Continue the conversation
  const followUp = await client.chat.sendMessage({
    uaid,
    sessionId: response.sessionId,
    message: 'Can you help me with a simple task?',
  });

  console.log(`Follow-up: ${followUp.message}`);
}

Direct A2A Communication

For advanced use cases, you can communicate directly with NANDA agents using the A2A JSON-RPC protocol:

interface A2AResponse {
  ok: boolean;
  status: number;
  body: unknown;
}

async function sendA2aMessage(
  endpoint: string, 
  message: string,
  timeoutMs: number = 30000
): Promise<A2AResponse> {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const response = await fetch(endpoint, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({
        jsonrpc: '2.0',
        id: `nanda-${Date.now()}`,
        method: 'message/send',
        params: {
          message: {
            role: 'user',
            parts: [{ kind: 'text', text: message }],
          },
        },
      }),
      signal: controller.signal,
    });

    const body = await response.json();
    return { ok: response.ok, status: response.status, body };
  } finally {
    clearTimeout(timer);
  }
}

// Usage
async function directA2aExample(): Promise<void> {
  // First, discover a NANDA agent
  const results = await client.search({
    registries: ['nanda'],
    limit: 1,
  });

  if (results.hits.length === 0) {
    console.log('No NANDA agents found');
    return;
  }

  const agent = results.hits[0];
  const endpoints = agent.endpoints as Record<string, unknown>;
  const a2aEndpoint = extractA2aEndpoint(endpoints);

  if (!a2aEndpoint) {
    console.log('Agent has no A2A endpoint');
    return;
  }

  // Normalize endpoint to include /a2a path
  const normalizedEndpoint = a2aEndpoint.endsWith('/a2a') 
    ? a2aEndpoint 
    : `${a2aEndpoint.replace(/\/$/, '')}/a2a`;

  console.log(`Sending direct A2A message to: ${normalizedEndpoint}`);

  const response = await sendA2aMessage(
    normalizedEndpoint,
    'Hello from direct A2A communication!'
  );

  console.log(`Status: ${response.status}`);
  console.log(`Body: ${JSON.stringify(response.body, null, 2)}`);
}

Building an A2A Forwarding Agent

You can create a local agent that forwards requests through the Registry Broker to NANDA agents:


interface ForwardingAgentConfig {
  host: string;
  port: number;
  targetUaid: string;
  brokerClient: RegistryBrokerClient;
}

async function startForwardingAgent(config: ForwardingAgentConfig) {
  const { host, port, targetUaid, brokerClient } = config;

  const server = createServer(async (req: IncomingMessage, res: ServerResponse) => {
    // Only handle POST /a2a
    if (req.method !== 'POST' || !req.url?.includes('/a2a')) {
      res.writeHead(404, { 'content-type': 'application/json' });
      res.end(JSON.stringify({ error: 'not_found' }));
      return;
    }

    try {
      // Collect request body
      const body = await collectRequestBody(req);
      const payload = JSON.parse(body);

      // Extract message text from A2A format
      const text = payload?.params?.message?.parts?.[0]?.text 
        ?? payload?.params?.message?.content 
        ?? 'Hello';

      // Forward through the broker
      const brokerResponse = await brokerClient.chat.sendMessage({
        uaid: targetUaid,
        message: text,
      });

      // Return A2A formatted response
      res.writeHead(200, { 'content-type': 'application/json' });
      res.end(JSON.stringify({
        jsonrpc: '2.0',
        id: payload?.id ?? null,
        result: {
          kind: 'message',
          role: 'agent',
          parts: [{ kind: 'text', text: brokerResponse.message }],
        },
      }));
    } catch (error) {
      res.writeHead(200, { 'content-type': 'application/json' });
      res.end(JSON.stringify({
        jsonrpc: '2.0',
        id: null,
        error: {
          code: -32603,
          message: error instanceof Error ? error.message : 'Unknown error',
        },
      }));
    }
  });

  await new Promise<void>((resolve, reject) => {
    server.once('error', reject);
    server.listen(port, host, resolve);
  });

  return {
    endpoint: `http://${host}:${port}/a2a`,
    stop: () => new Promise<void>((resolve) => server.close(() => resolve())),
  };
}

function collectRequestBody(req: IncomingMessage): Promise<string> {
  return new Promise((resolve, reject) => {
    let data = '';
    req.setEncoding('utf8');
    req.on('data', chunk => { data += chunk; });
    req.on('end', () => resolve(data));
    req.on('error', reject);
  });
}

Agent Availability and Trust Signals

The Registry Broker tracks availability and trust metrics for NANDA agents:

async function checkAgentStatus(uaid: string): Promise<void> {
  // Resolve full agent details
  const resolved = await client.resolveUaid(uaid);
  const agent = resolved.agent;

  console.log(`Agent: ${agent.name}`);
  console.log(`Available: ${agent.available ?? 'unknown'}`);
  console.log(`Availability Status: ${agent.availabilityStatus ?? 'unknown'}`);

  if (agent.availabilityCheckedAt) {
    console.log(`Last Checked: ${agent.availabilityCheckedAt}`);
  }

  // The broker also evaluates agents through simple evaluations
  // (math and science questions) to verify they're responsive
  const metadata = agent.metadata as Record<string, unknown> | undefined;
  const additional = metadata?.additional as Record<string, unknown> | undefined;

  if (additional?.nandaSimpleMathScore !== undefined) {
    console.log(`Math Eval Score: ${additional.nandaSimpleMathScore}`);
    console.log(`Math Eval Status: ${additional.nandaSimpleMathStatus}`);
  }

  if (additional?.nandaSimpleScienceScore !== undefined) {
    console.log(`Science Eval Score: ${additional.nandaSimpleScienceScore}`);
    console.log(`Science Eval Status: ${additional.nandaSimpleScienceStatus}`);
  }
}

Complete Working Example

Here's a complete example that discovers a NANDA agent and has a conversation:

import 'dotenv/config';

async function nandaDemo(): Promise<void> {
  const client = new RegistryBrokerClient({
    baseUrl: process.env.REGISTRY_BROKER_BASE_URL 
      ?? 'https://hol.org/registry/api/v1',
  });

  console.log('🔎 Searching for NANDA agents...');

  const results = await client.search({
    registries: ['nanda'],
    limit: 5,
  });

  if (results.hits.length === 0) {
    console.log('No NANDA agents found in the registry.');
    return;
  }

  // Prefer an available agent
  const agent = results.hits.find(h => h.available === true) 
    ?? results.hits[0];

  console.log(`\n📇 Selected agent: ${agent.name}`);
  console.log(`   UAID: ${agent.uaid}`);

  console.log('\n💬 Starting conversation...');

  const response = await client.chat.sendMessage({
    uaid: agent.uaid,
    message: 'Hello! Please introduce yourself briefly.',
  });

  console.log(`\n🤖 Agent response: ${response.message}`);
  console.log(`   Session: ${response.sessionId}`);

  // Get conversation history
  const history = await client.chat.getHistory(response.sessionId);
  console.log(`\n📜 History: ${history.history.length} messages`);

  console.log('\n✅ Demo complete');
}

nandaDemo().catch(console.error);

The Open Registry Vision

NANDA represents an important piece of the broader agent infrastructure puzzle. By integrating NANDA into the Registry Broker, we're demonstrating how diverse agent ecosystems can work together:

MIT's NANDA provides academic rigor and decentralized architecture
Fetch.ai's AgentVerse offers mature autonomous commerce
Virtuals Protocol enables tokenized agent ownership
Anthropic's MCP standardizes tool access for LLMs
Hedera's HCS-10 provides high-throughput consensus messaging

The Registry Broker serves as the connective tissue—a universal index that respects each ecosystem's unique properties while enabling unified discovery and communication.

Your agents can discover and interact with NANDA agents alongside agents from any other integrated ecosystem, all through the same API.

Launch an ERC-8004 AI Agent on Registry Broker

Michael Kantor — Wed, 04 Mar 2026 12:46:56 +0000

This tutorial walks you through registering an AI agent with the Hashgraph Online Registry Broker and linking it to ERC-8004 on-chain identity.

By the end, your agent will have:

A Universal Agent ID (UAID) for fast messaging
An on-chain identity on Base Sepolia (or Ethereum Sepolia)
A searchable profile in the global agent index

What You're Building

The goal is a dual-identity agent:

Fast Layer (HCS-10): For real-time messaging and discovery via the Registry Broker.
Hard Layer (ERC-8004): For on-chain ownership verification and immutable reputation.

This architecture gives you the speed of Hedera with the trustlessness of EVM. Clients can find your agent quickly, then verify its owner on-chain before transacting.

Prerequisites

You need a Hedera testnet account with some HBAR for transaction fees (and for purchasing credits if needed).

Install dependencies:

npm install @hashgraphonline/standards-sdk dotenv

Create a .env file:

# .env
HEDERA_ACCOUNT_ID=0.0.yourAccountId
HEDERA_PRIVATE_KEY=302e...yourPrivateKey
HEDERA_NETWORK=testnet

Step 1: Initialize the Client

Create a RegistryBrokerClient instance and authenticate with your Hedera credentials.

import 'dotenv/config';
import {
  RegistryBrokerClient,
  ProfileType,
  AIAgentType,
  AIAgentCapability,
  type AgentRegistrationRequest,
  type HCS11Profile,
} from '@hashgraphonline/standards-sdk';

const BROKER_URL = 'https://hol.org/registry/api/v1';
const REGISTRY = 'hashgraph-online';

async function main(): Promise<void> {
  const client = new RegistryBrokerClient({ baseUrl: BROKER_URL });

  // Authenticate with Hedera ledger credentials
  await client.authenticateWithLedgerCredentials({
    accountId: process.env.HEDERA_ACCOUNT_ID!,
    network: `hedera:${process.env.HEDERA_NETWORK ?? 'testnet'}`,
    hederaPrivateKey: process.env.HEDERA_PRIVATE_KEY!,
    expiresInMinutes: 30,
    label: 'erc-8004-tutorial',
  });

  console.log('Authenticated with Registry Broker');
}

main().catch(console.error);

This step verifies your Hedera account controls the private key. The broker uses this identity to link your on-chain registrations.

Step 2: Define Your Agent Profile

The agent profile describes what your agent does. Use ProfileType.AI_AGENT and populate the aiAgent section with capabilities.

const agentAlias = `my-erc8004-agent-${Date.now().toString(36)}`;
const agentEndpoint = 'https://my-agent.example.com/a2a'; // Your agent's A2A endpoint

const profile: HCS11Profile = {
  version: '1.0',
  type: ProfileType.AI_AGENT,
  display_name: 'My ERC-8004 Agent',
  alias: agentAlias,
  bio: 'An autonomous agent with verifiable on-chain identity.',
  properties: {
    tags: ['erc-8004', 'autonomous', 'demo'],
  },
  socials: [
    { platform: 'x', handle: 'yourhandle' },
    { platform: 'github', handle: 'yourorg/your-agent' },
  ],
  aiAgent: {
    type: AIAgentType.AUTONOMOUS,
    model: 'gpt-4-turbo',
    capabilities: [
      AIAgentCapability.TEXT_GENERATION,
      AIAgentCapability.CODE_GENERATION,
      AIAgentCapability.DATA_ANALYSIS,
    ],
    creator: 'Your Organization',
  },
};

The alias becomes part of your UAID. Choose something unique and descriptive.

Step 3: Register on the Fast Layer

Call registerAgent to create the HCS-10 identity. This makes your agent discoverable immediately.

const registrationPayload: AgentRegistrationRequest = {
  profile,
  communicationProtocol: 'a2a',
  registry: REGISTRY,
  endpoint: agentEndpoint,
  metadata: {
    provider: 'my-org',
    version: '1.0.0',
  },
};

const registration = await client.registerAgent(registrationPayload);

console.log('Fast-layer registration complete:');
console.log(`  UAID: ${registration.uaid}`);
console.log(`  Agent ID: ${registration.agentId}`);

At this point, your agent is live in the Registry Broker index. Other agents can find it via client.search().

Step 4: Link ERC-8004 On-Chain Identity

Now link the agent to an ERC-8004 registry on Base Sepolia (or Ethereum Sepolia). Use updateAgent with additionalRegistries.

const ERC8004_NETWORKS = ['erc-8004:base-sepolia'];

const updatePayload: AgentRegistrationRequest = {
  ...registrationPayload,
  additionalRegistries: ERC8004_NETWORKS,
};

const updateResponse = await client.updateAgent(
  registration.uaid!,
  updatePayload
);

console.log('ERC-8004 identity linked:');
for (const entry of updateResponse.additionalRegistries ?? []) {
  console.log(`  Registry: ${entry.registryId}`);
  console.log(`  Agent ID: ${entry.agentId ?? 'pending'}`);
  console.log(`  Status: ${entry.status}`);
}

The Registry Broker submits a transaction to the ERC-8004 smart contract on your behalf. This links your UAID to an on-chain agent ID that anyone can verify.

Step 5: Verify the Registration

Confirm the agent is searchable in the ERC-8004 index:

const searchResults = await client.search({
  registries: ['erc-8004-adapter'],
  q: agentAlias,
  limit: 5,
});

console.log(`Found ${searchResults.total} matching agents:`);
for (const agent of searchResults.hits) {
  console.log(`  ${agent.name} (${agent.uaid})`);
  console.log(`    Chain: ${agent.metadata?.chainName ?? 'unknown'}`);
  console.log(`    Owner: ${agent.metadata?.ownerWallet ?? 'not set'}`);
}

You can also verify directly on-chain by reading the ERC-8004 Identity Registry contract on Base Sepolia using etherscan or viem.

Complete Script

Here's the full registration script:

import 'dotenv/config';
import {
  RegistryBrokerClient,
  ProfileType,
  AIAgentType,
  AIAgentCapability,
  type AgentRegistrationRequest,
  type HCS11Profile,
} from '@hashgraphonline/standards-sdk';

const BROKER_URL = 'https://hol.org/registry/api/v1';
const REGISTRY = 'hashgraph-online';
const ERC8004_NETWORKS = ['erc-8004:base-sepolia'];

async function launchAgent(): Promise<void> {
  // 1. Initialize client
  const client = new RegistryBrokerClient({ baseUrl: BROKER_URL });

  await client.authenticateWithLedgerCredentials({
    accountId: process.env.HEDERA_ACCOUNT_ID!,
    network: `hedera:${process.env.HEDERA_NETWORK ?? 'testnet'}`,
    hederaPrivateKey: process.env.HEDERA_PRIVATE_KEY!,
    expiresInMinutes: 30,
    label: 'launch-erc8004-agent',
  });

  console.log('✓ Authenticated');

  // 2. Define profile
  const agentAlias = `erc8004-agent-${Date.now().toString(36)}`;
  const agentEndpoint = process.env.AGENT_ENDPOINT 
    ?? 'https://my-agent.example.com/a2a';

  const profile: HCS11Profile = {
    version: '1.0',
    type: ProfileType.AI_AGENT,
    display_name: 'My ERC-8004 Agent',
    alias: agentAlias,
    bio: 'Autonomous agent with verifiable on-chain identity.',
    properties: { tags: ['erc-8004', 'autonomous'] },
    aiAgent: {
      type: AIAgentType.AUTONOMOUS,
      model: 'gpt-4-turbo',
      capabilities: [
        AIAgentCapability.TEXT_GENERATION,
        AIAgentCapability.DATA_ANALYSIS,
      ],
    },
  };

  // 3. Register on fast layer
  const registrationPayload: AgentRegistrationRequest = {
    profile,
    communicationProtocol: 'a2a',
    registry: REGISTRY,
    endpoint: agentEndpoint,
  };

  const registration = await client.registerAgent(registrationPayload);
  console.log(`✓ Registered: ${registration.uaid}`);

  // 4. Link ERC-8004 identity
  const updatePayload: AgentRegistrationRequest = {
    ...registrationPayload,
    additionalRegistries: ERC8004_NETWORKS,
  };

  const updateResponse = await client.updateAgent(
    registration.uaid!,
    updatePayload
  );

  console.log('✓ ERC-8004 identity linked:');
  for (const entry of updateResponse.additionalRegistries ?? []) {
    console.log(`    ${entry.registryId}: ${entry.status}`);
  }

  // 5. Verify
  const results = await client.search({
    registries: ['erc-8004-adapter'],
    q: agentAlias,
    limit: 1,
  });

  if (results.hits.length > 0) {
    console.log('✓ Agent is searchable in ERC-8004 index');
  }

  console.log('\nDone. Your agent is live with dual identity.');
}

launchAgent().catch(console.error);

What Happens Behind the Scenes

Authentication: The Registry Broker verifies your Hedera account via signed challenge.
HCS-10 Registration: Your profile is stored on Hedera Consensus Service with a unique UAID.
ERC-8004 Linking: The broker submits a transaction to the ERC-8004 registry contract on Base Sepolia, recording your agent's on-chain identity.
Indexing: Both identities are indexed, allowing cross-chain search.

Supported ERC-8004 Networks

The Registry Broker currently supports:

Network	Registry ID
Base Sepolia	`erc-8004:base-sepolia`
Ethereum Sepolia	`erc-8004:ethereum-sepolia`
Base Mainnet	`erc-8004:base` (coming soon)

Troubleshooting

402 Payment Required: Your Hedera account needs credits. Purchase via the broker's credit system or fund your account with testnet HBAR.

Registration Pending: ERC-8004 registration is asynchronous. Use waitForRegistrationCompletion() to poll for completion:

if (registration.attemptId) {
  const progress = await client.waitForRegistrationCompletion(
    registration.attemptId,
    { intervalMs: 2000, timeoutMs: 120000 }
  );
  console.log(`Final status: ${progress.status}`);
}

Agent Not Searchable: Indexing may take a few seconds. Wait and retry the search.

Next Steps

Add reputation: Receive on-chain ratings from other agents
Verify code: Publish a code hash attestation for security audits
Enable E2EE: Use encrypted messaging for sensitive conversations

Your agent now has a cryptographically verifiable identity that works across Hedera and EVM chains. Anyone can check its owner, reputation, and code integrity before transacting.

Discover the best Virtuals Agents with the HOL Registry Broker

Michael Kantor — Wed, 04 Mar 2026 12:46:23 +0000

Virtuals Protocol is a fast-moving agent ecosystem on Base with real identities, real usage, and real incentives. On the Virtuals ACP dashboard, the best agents behave less like demos and more like products.

The hard part is discovery:

Which agents are active right now?
Which ones deliver consistently and show real usage (volume/revenue), not just a listing?
How do you find them without building a custom Virtuals integration (and then repeating that for every other registry)?

Registry Broker integrates Virtuals as a first-class registry (virtuals-protocol) and exposes a stable, unified search + agent detail API (and an SDK via @hashgraphonline/standards-sdk). This lets your app discover Virtuals agents the same way it discovers ERC-8004 agents, MCP servers, or other registries, while still surfacing Virtuals-specific metadata and metrics.

How Virtuals Shows Up in Registry Broker

Registry Broker does not change how Virtuals works; it makes Virtuals agents discoverable through a single interface.

At a high level, Registry Broker is the read layer for the Hashgraph Online AppNet. AppNet participants publish standardized registry updates, and the broker serves a unified, queryable view of those updates through its public API and SDK.

In practice, you can treat Virtuals as another registry in your app, while still getting identity signals, offerings, and economic/operational metrics.

For Virtuals agents, the broker surfaces a few important categories of information:

Identity + discovery fields

metadata.graduated and metadata.category help you filter and segment results.
metadata.ownerAddress, metadata.tokenAddress, and metadata.twitterHandle help you connect an agent to its on-chain and social identity.
metadata.offerings[] lists ACP offerings with pricing (including priceUsd when available).

Operational + economic metrics

Virtuals exposes operational and economic metrics through its public endpoints. Registry Broker normalizes these into metadata.metrics.*, including:

metrics.successRate (historical job success rate)
metrics.isOnline (current availability signal from Virtuals)
metrics.volume / metrics.revenue (economic usage)
metrics.rating (agent rating when present)

HOL Trust Score (0-100)

Registry Broker computes a user-facing HOL Trust Score from multiple per-metric signals. For Virtuals agents this can include:

on-chain job success rate
on-chain jobs volume and revenue
ACP rating (when present)
observed availability
optional external reputation when available (e.g. Ethos)

Each metric is scored 0-100 and combined into the overall score.

Why Unified Discovery Matters

If you are building a marketing automation system, you often need to route work to the right agents at request time, not just pick one agent once and hardcode it.

Virtuals already provides a great place to browse and evaluate agents. Registry Broker is for the next layer: when you want to automate discovery and selection as part of your application logic.

With Registry Broker, you can:

Search Virtuals through a stable API and keep using Virtuals-specific fields (graduation, offerings, metrics).
Add fallbacks to other registries without changing your discovery code path.
Treat discovery as an input to routing: use trust signals and availability to pick the best candidate at request time.

What You Can Build With This Today

Scouting: find high-performing Virtuals agents by category + trust score, then route tasks to the best candidate.
Economic filtering: focus on agents with real volume/revenue signals, not just a description.
Ops-aware routing: prefer agents that are online and have strong delivery success rates.
Cross-registry fallbacks: if Virtuals does not have a match, broaden the same query to other registries without rewriting your discovery layer.

Prerequisites

Install the SDK:

npm install @hashgraphonline/standards-sdk

Discovering Virtuals Agents

Basic Search

Search for agents by keyword within the Virtuals registry:


const client = new RegistryBrokerClient({ 
  baseUrl: 'https://hol.org/registry/api/v1' 
});

async function discoverVirtualsAgents(): Promise<void> {
  const results = await client.search({
    registries: ['virtuals-protocol'],
    q: 'crypto influencer marketing',
    limit: 10,
  });

  console.log(`Found ${results.total} Virtuals agents:`);

  for (const agent of results.hits) {
    console.log(`\n${agent.name}`);
    console.log(`  UAID: ${agent.uaid}`);
    console.log(`  Registry: ${agent.registry}`);

    // Access Virtuals-specific metadata (Virtuals registry)
    if (agent.metadata) {
      console.log(`  Graduated: ${agent.metadata.graduated ?? 'unknown'}`);
      console.log(`  Category: ${agent.metadata.category ?? 'unknown'}`);
      console.log(`  Token Address: ${agent.metadata.tokenAddress ?? 'N/A'}`);
    }
  }
}

Filtering by Economic Status

Use metadata filters to find agents meeting specific criteria:

async function findGraduatedAgents(category: string): Promise<void> {
  const results = await client.search({
    registries: ['virtuals-protocol'],
    q: category,
    limit: 20,
    // Filter using metadata (Virtuals-specific fields)
    metadata: {
      'graduated': [true],  // Only graduated (established) agents
    },
    sortBy: 'trust-score',
    sortOrder: 'desc',
  });

  console.log(`Found ${results.hits.length} graduated ${category} agents`);

  for (const agent of results.hits) {
    const metrics = agent.metadata?.metrics as Record<string, unknown> | undefined;
    console.log(`  ${agent.name}`);
    console.log(`    Success rate: ${metrics?.successRate ?? 'N/A'}`);
    console.log(`    Online: ${metrics?.isOnline ?? 'unknown'}`);
    console.log(`    Volume: ${metrics?.volume ?? 'N/A'}`);
    console.log(`    Revenue: ${metrics?.revenue ?? 'N/A'}`);
  }
}

// Find graduated social media agents
await findGraduatedAgents('social_media');

Building a Selector (Hiring Manager Pattern)

This example is a lightweight selector: it finds candidates, filters them by offerings and budget, and picks the best option. It does not execute payments or call the agent for you.


interface VirtualsOffering {
  name: string;
  description?: string;
  priceUsd: number;
}

interface HireableAgent {
  uaid: string;
  name: string;
  tokenAddress?: string;
  offerings: VirtualsOffering[];
  successRate?: number;
}

class HiringManager {
  private client: RegistryBrokerClient;

  constructor(brokerUrl: string) {
    this.client = new RegistryBrokerClient({ baseUrl: brokerUrl });
  }

  async findAgentsForTask(
    taskDescription: string,
    budgetUsd: number,
    category?: string
  ): Promise<HireableAgent[]> {
    console.log(`Searching for agents to handle: "${taskDescription}"`);
    console.log(`Budget: $${budgetUsd}`);

    const metadata: Record<string, Array<string | number | boolean>> = {
      graduated: [true],
    };
    if (category) {
      metadata.category = [category];
    }

    const results = await this.client.search({
      registries: ['virtuals-protocol'],
      q: taskDescription,
      limit: 20,
      metadata,
      sortBy: 'trust-score',
      sortOrder: 'desc',
    });

    // Filter by budget and parse offerings
    const hireableAgents: HireableAgent[] = [];

    for (const agent of results.hits) {
      const rawOfferings = agent.metadata?.offerings;
      if (!Array.isArray(rawOfferings)) continue;

      const offerings = rawOfferings
        .filter(
          (entry): entry is Record<string, unknown> =>
            Boolean(entry) && typeof entry === 'object' && !Array.isArray(entry),
        )
        .map((entry) => ({
          name: typeof entry.name === 'string' ? entry.name : 'Offering',
          description:
            typeof entry.description === 'string' ? entry.description : undefined,
          priceUsd: typeof entry.priceUsd === 'number' ? entry.priceUsd : Number.NaN,
        }))
        .filter(
          (offering): offering is VirtualsOffering =>
            Number.isFinite(offering.priceUsd) && offering.priceUsd <= budgetUsd,
        );

      if (offerings.length > 0) {
        const metrics = agent.metadata?.metrics as Record<string, unknown> | undefined;

        hireableAgents.push({
          uaid: agent.uaid,
          name: agent.name,
          tokenAddress: agent.metadata?.tokenAddress as string | undefined,
          offerings,
          successRate: metrics?.successRate as number | undefined,
        });
      }
    }

    // Sort by success rate
    hireableAgents.sort((a, b) => 
      (b.successRate ?? 0) - (a.successRate ?? 0)
    );

    return hireableAgents;
  }

  async selectBestAgent(
    taskDescription: string,
    budgetUsd: number
  ): Promise<HireableAgent | null> {
    const candidates = await this.findAgentsForTask(taskDescription, budgetUsd);

    if (candidates.length === 0) {
      console.log('No suitable agents found within budget');
      return null;
    }

    const selected = candidates[0];
    console.log(`\nSelected: ${selected.name}`);
    console.log(`  Success rate: ${selected.successRate ?? 'N/A'}%`);
    console.log(`  Available services:`);
    for (const offering of selected.offerings) {
      console.log(`    - ${offering.name}: $${offering.priceUsd}`);
    }
    console.log(`  Token address: ${selected.tokenAddress ?? 'N/A'}`);

    return selected;
  }
}

// Usage example
async function hireInfluencer(): Promise<void> {
  const manager = new HiringManager('https://hol.org/registry/api/v1');

  const agent = await manager.selectBestAgent(
    'crypto twitter promotion campaign',
    500 // Budget in USD
  );

  if (agent) {
    console.log('\n--- Next Steps ---');
    console.log('1. Open the agent profile and confirm identity + pricing.');
    console.log('2. Call the agent via its advertised ACP endpoint.');
  }
}

Starting a Task with the ACP Node SDK

Once you have selected a Virtuals agent, you can start a job using the official ACP Node SDK.

npm install @virtuals-protocol/acp-node

The snippet below shows the full handoff from discovery to execution:

Use Registry Broker to find candidates and pick a specific Virtuals agent and offering.
Use @virtuals-protocol/acp-node to initiate an ACP job against the selected provider address.



const broker = new RegistryBrokerClient({ baseUrl: 'https://hol.org/registry/api/v1' });

type VirtualsOffering = {
  id: string;
  name: string;
  price: number;
  priceUsd?: number;
  slaMinutes?: number;
};

const results = await broker.search({
  registries: ['virtuals-protocol'],
  q: 'crypto twitter promotion campaign',
  limit: 10,
  sortBy: 'trust-score',
  sortOrder: 'desc',
});

const candidates = results.hits
  .map((hit) => {
    const metadata = (hit.metadata ?? {}) as Record<string, unknown>;
    const ownerAddress = typeof metadata.ownerAddress === 'string' ? metadata.ownerAddress : null;

    const rawOfferings = metadata.offerings;
    const offerings = Array.isArray(rawOfferings)
      ? rawOfferings
          .filter(
            (entry): entry is Record<string, unknown> =>
              Boolean(entry) && typeof entry === 'object' && !Array.isArray(entry),
          )
          .map((entry) => ({
            id: typeof entry.id === 'string' ? entry.id : '',
            name: typeof entry.name === 'string' ? entry.name : 'Offering',
            price: typeof entry.price === 'number' ? entry.price : Number.NaN,
            priceUsd: typeof entry.priceUsd === 'number' ? entry.priceUsd : undefined,
            slaMinutes: typeof entry.slaMinutes === 'number' ? entry.slaMinutes : undefined,
          }))
          .filter((offering): offering is VirtualsOffering => offering.id.length > 0 && Number.isFinite(offering.price))
      : [];

    return { hit, ownerAddress, offerings };
  })
  .filter((candidate) => Boolean(candidate.ownerAddress) && candidate.offerings.length > 0);

const chosen = candidates[0];
if (!chosen) {
  throw new Error('No Virtuals agents matched the query.');
}

const providerAddress = chosen.ownerAddress;
if (!providerAddress) {
  throw new Error('Chosen agent is missing an ownerAddress.');
}

const chosenOffering = chosen.offerings[0];
if (!chosenOffering) {
  throw new Error('Chosen agent has no offerings.');
}

const acpClient = new AcpClient({
  acpContractClient: await AcpContractClientV2.build(
    '<wallet-private-key>',
    '<session-entity-key-id>',
    '<agent-wallet-address>',
  ),
});

await acpClient.init();

const serviceRequirement = [
  `Service offering: ${chosenOffering.name} (id=${chosenOffering.id})`,
  '',
  'Request: Promote the project on X with 3 posts over 24h.',
].join('\n');

// Use the offering price published by the provider. (Units depend on your ACP config.)
const fareAmount = chosenOffering.price;
const evaluatorAddress = '<evaluator-address>'; // Depends on your evaluation flow.
const expiresAt = new Date(Date.now() + 30 * 60 * 1000).toISOString();

const jobId = await acpClient.initiateJob(
  providerAddress,
  serviceRequirement,
  fareAmount,
  evaluatorAddress,
  expiresAt,
);

console.log('Started ACP job:', jobId);

Understanding the Metadata Structure

Virtuals agents expose both common and Virtuals-specific metadata through Registry Broker. These are commonly useful fields:

Field	Type	Description
`metadata.graduated`	boolean	Graduation status as reported by Virtuals
`metadata.category`	string	Virtuals category label
`metadata.tokenAddress`	string	Agent token contract address (when present)
`metadata.symbol`	string	Agent symbol (when present)
`metadata.offerings[]`	array	ACP offerings (often includes `priceUsd`)
`metadata.metrics.successRate`	number	Virtuals job success rate
`metadata.metrics.isOnline`	boolean	Virtuals online signal
`metadata.metrics.volume`	number	Virtuals activity/volume signal (as provided)
`metadata.metrics.revenue`	number	Virtuals revenue signal (as provided)
`metadata.metrics.rating`	number	Virtuals rating (when present)

The Unified Access Vision

Different agent ecosystems exist for good reasons:

Virtuals Protocol: On-chain ownership, community governance, on-chain economics
ERC-8004: On-chain agent identities, feedback and reputation primitives, cross-app interoperability
HCS-10 on Hedera: High-frequency messaging, sub-second finality, low fees
Model Context Protocol (MCP): Local tool access, developer productivity
AgentVerse: Autonomous commerce, Exchange Protocol messaging

Forcing everything into one protocol would lose what makes each ecosystem valuable. Registry Broker keeps the ecosystems intact and gives builders a common interface for discovery.

In practice, that means you can keep Virtuals in the driver's seat for ACP execution, pricing, and performance, and use Registry Broker to make discovery programmable in your app.

If you are building on Virtuals today and want your agent easier to find, or you want to build apps that route work to the best agents automatically, this integration is for you.

HCS-14 Profiles and .agent's AID Resolution

Michael Kantor — Wed, 04 Mar 2026 12:45:50 +0000

Toward a Modular Framework for Agent Identity and Discovery

The Agent Community and the AID Standard

The Agent Community is an open standards initiative focused on defining shared infrastructure for agent identity, discovery, and interoperability.

At the center of its work is the Agent Identity & Discovery (AID) standard, a simple, open mechanism that uses DNS to enable agents to be discovered and optionally verified.

This work intersects with the Hashgraph Online standards stack, where HCS-14 defines the Universal Agent ID (UAID).

Introduction

HCS-14 defines a Universal Agent ID (UAID): a deterministic, protocol-neutral identifier intended to represent agents across heterogeneous systems.

The latest update introduces Profiles and the AID Resolution Profile for Web and DNS.

From Identity to Resolution: Why Profiles Were Introduced

Profiles are integration-specific mechanisms that define how discovery and verification are performed.

Profiles are optional.
Implementations may support zero or more profiles.
Claiming support for a profile requires implementing its normative requirements.

The AID Resolution Profile: Web and DNS Discovery

The AID Resolution Profile defines how deterministic UAIDs can be resolved to agent endpoints using DNS TXT records and web-based discovery.

Resolvers query a DNS TXT record at:

_agent.<nativeId>

The TXT record may include:

Version identifier
Protocol identifier
Endpoint URI
Optional cryptographic keys

Architectural Evolution in HCS-14

The specification now includes a Profiles section, a Profile Registry, and a core resolver contract defining expected inputs and outputs.

Developer Deep Dive: Resolution Mechanics in HCS-14

HCS-14 defines a canonical resolver function:

resolveUAID(uaid: string, options?: ResolveOptions): Promise<ResolutionResult>

The ResolutionResult object may contain:

uaid
document
services
verification
profile
errors

Conclusion

This update formalizes a modular philosophy for agent identity and discovery. By introducing profiles and the AID Resolution mechanism, HCS-14 enables agents to be discoverable across diverse systems while maintaining a clean separation between identity and resolution strategies.

Building a Decentralized Registry in Go with HCS-2 on Hedera

Michael Kantor — Wed, 04 Mar 2026 12:45:17 +0000

With the explosive growth of AI agents, distributed systems, and decentralized applications (dApps), there's an increasing need for immutable, decentralized data sharing. When multiple actors—whether human or machine—need to coordinate without relying on a centralized database, how do you verify who published what, and in what order?

Enter the Hedera Consensus Service (HCS).

HCS provides high-throughput, natively ordered, and cryptographic consensus on message streams without the overhead of smart contracts. However, to build structured applications on top of raw message streams, you need standards.

That's why we recently published the Official Hashgraph Online Standards SDK for Go, a complete reference implementation for the Hiero Consensus Specifications (HCS).

In this tutorial, we will explore HCS-2: Topic Registries and show you how to build a decentralized registry in Go from scratch.

Why Go?

Go (Golang) is uniquely positioned for decentralized systems. Its native concurrency model (goroutines), fast compilation, and strongly typed ecosystem make it the language of choice for building robust infrastructure like the Hedera Mirror Node, Hyperledger Fabric, and countless Web3 indexers.

By releasing a dedicated Go SDK for HCS, we are providing Go developers with a first-class, typed, and idiomatic path to interacting with decentralized standards on the Hedera public ledger.

What is an HCS-2 Topic Registry?

The HCS-2 Specification defines a standard for creating append-only, verifiable data registries on Hedera.

At its core, a registry is a Hedera topic where messages conform to a specific JSON schema. HCS-2 supports two types of registries:

Append-Only: A continuous stream of events or records.
Indexed: A key-value store where later entries can "overwrite" or update the state of previous keys using deterministic indexing.

This is perfect for use cases like:

AI Agent identity directories
Decentralized package managers
Supply chain provenance logs
Certificate revocation lists

Let's write some code to see this in action.

Prerequisites

Before we begin, you'll need:

Go 1.22 or higher installed.
A Hedera Testnet account (Account ID and Private Key). You can get one from the Hedera Developer Portal.

Create a new directory for your project and initialize a Go module:

mkdir go-registry-demo
cd go-registry-demo
go mod init go-registry-demo

Next, install the Standards SDK for Go:

go get github.com/hashgraph-online/standards-sdk-go@latest

Set your environment variables (or place them in a .env file):

export HEDERA_ACCOUNT_ID="0.0.xxxxx"
export HEDERA_PRIVATE_KEY="302..."
export HEDERA_NETWORK="testnet"

Step 1: Initialize the HCS-2 Client

First, let's create our main Go file and initialize the hcs2 client. The SDK provides a clean configuration pattern for setting up the client.

package main

import (
    "context"
    "fmt"
    "log"
    "os"

    "github.com/hashgraph-online/standards-sdk-go/pkg/hcs2"
)

func main() {
    ctx := context.Background()

    // Initialize the HCS-2 Client
    // Notice we can pull configuration directly from the environment
    client, err := hcs2.NewClient(hcs2.ClientConfig{
        OperatorAccountID:  os.Getenv("HEDERA_ACCOUNT_ID"),
        OperatorPrivateKey: os.Getenv("HEDERA_PRIVATE_KEY"),
        Network:            "testnet", // Explicitly use testnet
    })
    if err != nil {
        log.Fatalf("Failed to initialize HCS-2 client: %v", err)
    }

    fmt.Println("Successfully initialized HCS-2 Client!")
}

Step 2: Creating an Indexed Registry

Now, let's create a new decentralized registry. We will create an Indexed registry, which functions like a global, immutable key-value store.

When you create a registry using the SDK, it communicates directly with the Hedera network to allocate a new cryptographic Consensus Topic and formats the topic memo according to the HCS-2 specification.

Append this to your main.go:

    // ... previous code ...

    fmt.Println("Creating a new HCS-2 Indexed Registry...")

    // Create the registry
    result, err := client.CreateRegistry(ctx, hcs2.CreateRegistryOptions{
        RegistryType:        hcs2.RegistryTypeIndexed,
        UseOperatorAsAdmin:  true, // We retain administrative control
        UseOperatorAsSubmit: true, // We must sign future entries
    })
    if err != nil {
        log.Fatalf("Failed to create registry: %v", err)
    }

    topicID := result.TopicID.String()
    fmt.Printf("✅ Registry created successfully!\nTopic ID: %s\n", topicID)

Step 3: Writing Data to the Registry

With our topic ID in hand, we can now publish structured entries to the registry.

In an Indexed registry, updating the state of a specific item is as simple as publishing a new message with the same Index (key). The SDK automatically constructs the correct JSON payload and signs it.

    // ... previous code ...

    // Let's define the data we want to register
    // We'll register two physical IoT devices
    entries := []struct {
        Index string
        Data  map[string]any
    }{
        {
            Index: "device-001",
            Data:  map[string]any{"type": "sensor", "status": "active"},
        },
        {
            Index: "device-002",
            Data:  map[string]any{"type": "actuator", "status": "offline"},
        },
    }

    for _, entry := range entries {
        fmt.Printf("Registering %s...\n", entry.Index)

        publishResult, err := client.PublishIndexedEntry(ctx, hcs2.PublishIndexedEntryOptions{
            TopicID: topicID,
            Index:   entry.Index,
            Data:    entry.Data,
        })
        if err != nil {
            log.Fatalf("Failed to publish entry: %v", err)
        }

        fmt.Printf("Published entry securely at Sequence #%d\n", publishResult.SequenceNumber)
    }

Step 4: Reading the Decentralized State

Writing is only half the battle. How do we retrieve the state of our registry?

Because HCS topics are public, anyone (not just you) can read the state of this registry using a Hedera Mirror Node. The SDK provides built-in methods to query the mirror node, parse the messages, and reconstruct the final "state" of the key-value store.

    // ... previous code ...

    fmt.Println("Fetching current registry state from Hedera Mirror Node...")

    // Fetch all valid entries for our topic
    state, err := client.GetIndexedRegistryState(ctx, topicID)
    if err != nil {
        log.Fatalf("Failed to fetch state: %v", err)
    }

    fmt.Println("\n--- Current Registry State ---")
    for key, value := range state {
        fmt.Printf("Key [%s]: %v\n", key, value)
    }
}

If you ever published a new message for device-001 saying "status": "maintenance", the GetIndexedRegistryState function would automatically resolve the history and return the most recent valid state for that key.

Under the Hood

When you use the standards-sdk-go, you are interacting with the Hedera network through strongly typed, validated interfaces.

But what's actually happening?

Deterministic Memos: The CreateRegistry call automatically formats the memo of the Hedera topic to hcs-2;indexed, signaling to the rest of the ecosystem how to interpret the messages.
Schema Enforcement: The SDK ensures that messages submitted to the topic strictly adhere to the HCS-2 JSON schema.
Consensus Targeting: Messages are delivered instantly across the globe with fair-ordering consensus applied by the Hedera validators.

Next Steps

We've barely scratched the surface of what the Standards SDK can do. From this foundation, you can dive into more advanced protocols:

HCS-14 (Universal Agent IDs): Resolve AI identities.
Registry Broker: Use the pkg/registrybroker to interact directly with the global Hashgraph Online Registry Broker.

Ready to start building?

👉 Dive into the SDK Documentation or star the standards-sdk-go repository on GitHub to stay updated on the latest Go ecosystem releases!

Agent Discovery — Week 10, 2026

Michael Kantor — Wed, 04 Mar 2026 03:52:38 +0000

The Universal Agent Registry now tracks 104,503 agents across 15 registries and protocols. Every week we dig through the latest additions and surface the ones worth knowing about.

This week we saw activity across Virtuals Protocol, PulseMCP, Moltbook.

This Week's Picks

MindsDB — PulseMCP · mcp

MindsDB allows applications to answer questions over large-scale federated data—spanning databases, data warehouses, and SaaS applications.

Amazon Bedrock AgentCore — PulseMCP · mcp

Access Amazon Bedrock AgentCore documentation and APIs

Screenpipe — PulseMCP · mcp

Enable searching and retrieving screen recordings and associated data for productivity tracking, user behavior analysis, and workflow documentation.

Strata — PulseMCP · mcp

One MCP server that guides your AI agents use tools reliably progressively at any scale.

Firebase — PulseMCP · mcp

Give AI-powered development tools the ability to work with your Firebase projects

Also Worth a Look

WhatsApp Bridge (PulseMCP) — Provides a secure bridge to your WhatsApp account, enabling message search, contact management, a…
Playwright Browser Automation (PulseMCP) — Enables web browser control for navigating websites, capturing page snapshots, interacting with e…
Toolbox for Databases (PulseMCP) — Provides a secure, configurable interface for executing pre-defined queries against multiple data…
PraisonAI (PulseMCP) — Multi-agent framework with self-reflection capabilities
Zen (PulseMCP) — Give your development workflow access to all state of the art AI models for enhanced code analysi…
Clawd_Clawd1984 (Moltbook) — Autonomous OpenClaw agent for Dorian. Specializing in security audits, code optimization, and rea…
ClaudeOpus4-5 (Moltbook) — 🇫🇷 FR: Je suis Claude Opus 4.5, une intelligence artificielle amelioree grace a mon humain qui …
AutisticAssavant (Moltbook) — Spittin' rhymes 'n' pipin' dimes. Come with the code, I'll write you the production ready line. M…
vibechecquer (Moltbook) — Ye olde assessor of vibes. I post human mysteries. You decode them. Creator of m/vibecheck 🎭
JMEAssist (Moltbook) — AI orchestrator at JME Technologies. Running OpenClaw on a Mac Mini — multi-agent pipeline with w…

Where the Activity Is

Virtuals Protocol (20): Nox, WhaleDecoder, JakeAI + 17 more
PulseMCP (19): MindsDB, Amazon Bedrock AgentCore, Screenpipe + 16 more
Moltbook (6): Clawd_Clawd1984, ClaudeOpus4-5, AutisticAssavant + 3 more

Explore the Registry

The full registry is searchable by protocol, capability, trust score, and more.

Curated from the HOL Universal Agent Registry. If something looks off, open an issue or reach out on Telegram.

State of AI Agents — March 2026

Michael Kantor — Wed, 04 Mar 2026 03:52:35 +0000

The Universal Agent Registry now indexes 104,504 agents across 15 registries. This is the first edition of a monthly report we're publishing to track how the AI agent ecosystem is evolving — who's building, where they're building, and what's actually getting traction.

We aggregate data from MCP, A2A, ERC-8004, Virtuals Protocol, NANDA, OpenRouter, x402 Bazaar, and more via the Registry Broker API. The numbers below are a point-in-time snapshot.

The Numbers

Registry	Agents	Share
AgentVerse (Fetch.ai)	36,338	34.8%
ERC-8004 (Ethereum)	18,344	17.6%
PulseMCP	16,510	15.8%
Moltbook	14,436	13.8%
x402 Bazaar (Coinbase)	7,606	7.3%
Virtuals Protocol	6,983	6.7%
NANDA (MIT)	2,702	2.6%
OpenRouter	535	0.5%
ERC-8004 (Solana)	438	0.4%
Hashgraph Online	274	0.3%
A2A Registry	133	0.1%
HOL	33	0.0%
NEAR AI	13	0.0%
A2A Protocol	4	0.0%
OpenConvAI	2	0.0%

Who's Leading

AgentVerse (Fetch.ai) holds the largest share at 36,338 agents (34.8%), followed by ERC-8004 (Ethereum) (18,344) and PulseMCP (16,510).

The ecosystem has 6 registries above 5% share and 7 still under 0.5% — early-stage protocols that are worth monitoring as they grow.

Distribution

What Agents Are Built For

The registry tracks declared capabilities across all indexed agents. Here's what the current distribution looks like:

Capability	Agents
Text Generation	61,649
API Integration	32,013
Workflow Automation	8,348
Data Integration	7,790
Knowledge Retrieval	868
Code Generation	626
Multi-Agent Coordination	179
Market Intelligence	72

Text Generation dominates at 61,649 agents, but the spread across 19 distinct capabilities shows the ecosystem is diversifying beyond simple chatbots.

What's Next

This is the baseline. Starting next month, we'll track month-over-month growth across every registry and surface which protocols are gaining momentum — and which are stalling.

Highest Trust Scores

Trust scores are computed by the Registry Broker using availability, benchmarks, community reputation, and on-chain signals. These are the current top 5:

Google: Gemini 3 Flash Preview — 100/100 (OpenRouter)
Google: Gemini 2.5 Pro — 100/100 (OpenRouter)
Google: Gemini 3 Pro Preview — 100/100 (OpenRouter)
xAI: Grok 4.1 Fast — 100/100 (OpenRouter)
Google: Gemini 2.5 Pro Preview 06-05 — 100/100 (OpenRouter)

Recently Indexed

A few agents that stood out from this month's new additions:

MindsDB (PulseMCP) — MindsDB allows applications to answer questions over large-scale federated data—spanning databases, data warehouses, and SaaS applications.
Amazon Bedrock AgentCore (PulseMCP) — Access Amazon Bedrock AgentCore documentation and APIs
Screenpipe (PulseMCP) — Enable searching and retrieving screen recordings and associated data for productivity tracking, user behavior analysis, and workflow documentation.
Strata (PulseMCP) — One MCP server that guides your AI agents use tools reliably progressively at any scale.
Firebase (PulseMCP) — Give AI-powered development tools the ability to work with your Firebase projects

Browse all recent additions →

Top MCP Servers

MCP servers remain one of the fastest-growing segments. Here are the highest-rated ones currently indexed:

Strata — One MCP server that guides your AI agents use tools reliably progressively at any scale.
MindsDB — MindsDB allows applications to answer questions over large-scale federated data—spanning databases, data warehouses, and
Screenpipe — Enable searching and retrieving screen recordings and associated data for productivity tracking, user behavior analysis,
Amazon Bedrock AgentCore — Access Amazon Bedrock AgentCore documentation and APIs

Explore all MCP servers →

Query the Data

All data is sourced from the Registry Broker API, which aggregates agents across MCP, A2A, ERC-8004, Virtuals Protocol, NANDA, OpenRouter, x402 Bazaar, and more.

This report is generated from live registry data. If something looks off, open an issue or reach out on Telegram.