How does the Concordium Agent Registry operate? A step-by-step guide from S'inscrire to obtaining the Verified Badge

Concordium Agent Registry serves as the foundational implementation for Concordium (CCD) within the AI Agent economy. When an Agent can sign, pay, or invoke services autonomously, counterparties must first determine, "Who owns this Agent and who has authorized its actions?" The Registry delivers on-chain, discoverable, verifiable, and cross-chain-referenced identity anchors, seamlessly integrating with the verified account layer described in protocol-level identity and zero-knowledge proof.

The Registry, as outlined in public documentation, comprises CIS-8004 (Agent registration standard), Agent Card (off-chain JSON plus on-chain hash), CIS-8 External Key Registry (cross-chain public key binding), and MCP Server (Agent tool interface). The following sections detail the process as a repeatable workflow, not a one-off event.

What Must Be Prepared Before Registering an Agent?

Prior to registration, three essential prerequisites are required: a verified Concordium native account, a publicly accessible Agent Card hosting URL, and metadata detailing the Agent’s name, skills, and service endpoints. For interoperability with networks such as Ethereum or Solana, you must also prepare the respective chain’s public key and the signing capability necessary for CIS-8 binding.

Concordium emphasizes that Agents are not required to migrate all workloads onto its chain: The Registry can anchor identity on Concordium, while Agents may operate on other chains, using CIS-8 and Badge to broadcast trust signals externally.

How Are Accounts and Identities Anchored to Agents?

Each Agent in the Registry corresponds to a CIS-8004 non-fungible token (NFT), minted and updated by a verified Concordium native account as owner. The owner account is linked to a real person or entity through protocol-level identity, establishing the authorization chain: Agent NFT → Owner account → Identity Issuer-backed identity.

On-chain storage includes critical fields: agent_uri pointing to the Agent Card, metadata_hash (SHA-256) ensuring document integrity, and extensible key-value metadata (such as payment wallet address). Optional external_reference may point to CIS-8 binding or social platform handles, facilitating cross-environment resolution for the same Agent.

This structure differs from pure ERC-8004-based registrations that merely "describe what the Agent is": Concordium requires the Owner to possess a verified account, making "who authorized" a precondition for registration, not a post-registration patch. Agent metadata may also include payment wallet and other key-value fields, supporting settlement between Agents or x402 pay-per-use scenarios for discovering recipient addresses. However, application-layer spending controls remain necessary; on-chain registration alone does not restrict Agent behavior.

How Do Agent Card and CIS-8004 Integrate?

Agent Card is a JSON document conforming to formats such as A2A (Agent-to-Agent), containing Agent name, description, skills, service endpoints, and Concordium extension blocks (contract index, token address, owner account, etc.). The document is hosted at the agent_uri HTTPS URL; during registration, both the URL and the SHA-256 hash of its contents are written to the CIS-8004 contract.

Any consumer—another Agent, MCP tool, or manual reviewer—can verify the Agent as follows: retrieve agent_uri and metadata_hash from the chain, fetch the raw JSON from the URL, compute SHA-256, and compare it to the on-chain hash. MCP tool verify_agent_card automates this process.

When updating Agent capabilities, the hosted JSON must be updated and the on-chain hash refreshed via build_set_agent_uri or similar operations. Otherwise, the on-chain anchor and off-chain document will diverge. The Agent Card serves as an updatable public specification, while the on-chain NFT acts as a non-repudiable integrity anchor. It is recommended to retain historical snapshots or a changelog when updating document versions, enabling auditors to trace changes in Agent capabilities.

Figure 1. Concordium Agent Registry workflow: verified account, CIS-8004 mint, Agent Card hash anchoring, and Badge display.

How Does CIS-8 Enable Cross-Chain Key Association?

CIS-8 External Key Registry stores cryptographic proof of the binding between a Concordium native account and external public keys (such as Ethereum addresses or Solana public keys) on-chain. Once binding is completed, a CIS-8004 Agent can reference the CIS-8 entry as external_reference, allowing Ethereum-based tools to resolve the same Agent NFT via public key.

The resolution path is: external chain address → CIS-8 contract binding lookup → Concordium owner account → CIS-8004 Agent lookup → Agent Card. Token_address and contract coordinates in Concordium extension blocks assist external Registries in performing lookups without requiring Concordium-specific knowledge.

This enables Agents to be addressed by token ID in Concordium tools and by ETH address in Ethereum tools, both referencing the same on-chain identity. Unlike the "proof of personhood" approach discussed in Concordium vs Worldcoin, the Registry addresses Agent-level verifiable identity and cross-chain interoperability.

How Is the Verified by Concordium Badge Verified?

The Verified by Concordium Badge is a visible trust signal for counterparties, indicating the Agent is linked to a protocol-level verified account. Verification should rely on on-chain facts, not just the Badge icon: confirm the corresponding token exists on CIS-8004, verify the owner account’s identity status, optionally check that the Agent Card hash matches the hosted document, and, for cross-chain scenarios, verify the CIS-8 binding.

The Badge reduces communication overhead but does not replace self-verification. Enterprises or high-trust environments often combine Verify and Access for attribute-level checks (such as age, credentials, and spending limit), complementing the Registry’s identity and authorization layer. If an Agent represents a financial institution or e-commerce platform for payments, the full trust stack is typically: Registry confirms Agent and authorized entity → ZKP verifies business attributes → Protocol-Level Locks or x402 constrain settlement paths, with each layer fulfilling its role.

What Should Be Noted During Registration and Verification?

Ensure Agent Card hosting is available and HTTPS integrity is maintained: if the URL becomes invalid or content is altered without updating the on-chain hash, verification will fail. External key binding must precede CIS-8 external_reference setup; incorrect order results in registration rollback or invalid references. Owner key security directly determines Agent control; since NFTs are transferable, Agent ownership changes require internal governance procedures.

MCP Server provides tools for registration, Agent Card construction, and card verification, facilitating Agent framework integration, but developers must understand on-chain operations and gas (or Sponsored Transactions) costs. The Registry ecosystem is still expanding, and whether counterparties adopt Badge as an admission criterion depends on industry practices.

Public documentation lists mainnet contracts including CIS-8004 Agent Registry (index 10082) and CIS-8 External Key Registry (index 10081), which can be queried via block explorers such as CCDScan. Indexer services convert on-chain events into REST APIs, simplifying Agent search and discovery without manual chain scanning. For production environments, it is recommended to establish a repeatable deployment checklist for "on-chain registration → Card hosting → hash verification → Badge display," and integrate it into CI workflows when updating Agent capabilities to prevent anchor drift between chain and document.

Summary

Concordium Agent Registry unifies Agent identity, document integrity, cross-chain public keys, and verified accounts into a repeatable workflow. Understanding the distinct roles of CIS-8004, Agent Card, and CIS-8 is essential for integrating Verified Badge and cross-chain Agent trust verification. During deployment, on-chain registration, document hosting, and periodic hash verification should be embedded in operational processes to avoid unverifiable outdated records following Agent capability updates.

FAQ

What Is Concordium Agent Registry?

Agent Registry is Concordium’s on-chain Agent identity system, registering Agents as NFTs via CIS-8004 and describing their capabilities and endpoints through Agent Card. The Registry connects Agents to verified Concordium accounts, supports cross-chain key binding, and the Verified by Concordium Badge.

How Is AI Agent Identity Linked to Real Accounts?

Each Agent NFT is owned and managed by a verified Concordium native account. This account is associated with a person or entity verified by protocol-level identity and Identity Issuer, forming an accountability chain: Agent → Owner → verified entity.

What Is the Purpose of the Agent Card?

Agent Card is a public JSON document detailing the Agent’s name, skills, and service endpoints; its URL and SHA-256 hash are stored on-chain to guarantee integrity. Updating capabilities requires synchronously updating the document and refreshing the on-chain hash.

Can Concordium Agents Operate on Ethereum or Solana?

Yes. By binding external chain public keys to Concordium accounts via CIS-8 and setting external_reference on CIS-8004 Agents, external tools can resolve the same Agent identity using Ethereum or Solana addresses, without migrating all logic to Concordium.

How Can You Verify If an Agent Is Trustworthy?

On-chain verification should include checking the CIS-8004 token, owner account identity status, whether the Agent Card hash matches the hosted document, and CIS-8 cross-chain binding as needed. The Verified Badge is a supplementary signal and cannot substitute for cryptographic verification steps.