The Decentralized Model Context Protocol (DMCP) is the backbone of Decontext’s architecture. It implements an immutable, verifiable, and open registry for agent-readable schemas. These schemas define how autonomous agents understand and interact with Web3 primitives such as wallets, tokens, DAOs, KYC, and more.

In this article, we will take a deep dive into the Solidity contract powering DMCP, covering registry architecture, publishing constraints, immutability guarantees, and the underlying trust model.

DMCP is an on-chain registry for publishing context schemas. Each schema describes a structured data format that AI agents or Web3 tools can interpret and reason over. For example, a schema might define the expected format for an ERC-20 transfer interaction, a DAO proposal, or a KYC identity proof.

Instead of hardcoding logic into each agent, Decontext introduces schema-driven reasoning. Agents query DMCP, fetch standardized definitions, and use that context to guide behavior.

The DMCP contract is implemented in Solidity and deployed on Ethereum-compatible networks. It is designed to be modular, upgradeable via forks, and minimal in gas usage.

At the heart of the protocol is a registry that maps a unique string-based ID to a schema object:

mapping(string => Schema) public schemas;

Each schema includes the fields:

struct Schema {
string id;            // Unique key, e.g. "erc20-mcp"
string uri;           // IPFS or HTTPS pointer to JSON schema
address publisher;    // Wallet that deployed the schema
    uint256 timestamp;    // Block timestamp at publishing
    bool exists;          // Boolean to enforce uniqueness
}

Developers publish schemas via a single function:

    function publishSchema(string memory id, string memory uri) external {
    require(!schemas[id].exists, "Schema already exists");
    schemas[id] = Schema({
        id: id,
        uri: uri,
        publisher: msg.sender,
        timestamp: block.timestamp,
        exists: true
    });
    emit SchemaPublished(id, uri, msg.sender, block.timestamp);
}

The function:

• Requires schema id to be unique

• Stores metadata immutably

• Emits a SchemaPublished' event to aid indexers

The uri field points to an off-chain JSON document that defines the full schema structure. This may include:

• Context types (objects, arrays, primitives)

• Field constraints (required keys, types, regex patterns)

• Semantic annotations (agent-readable tags)

• Versioning metadata

This approach balances gas efficiency and extensibility. The core registry remains minimal, while schema evolution happens off-chain via IPFS or similar systems.

Schema IDs should follow a namespaced convention:

wallet-mcp
erc20-mcp
dao-voting
kyc-did

This enables agents to reason over context categories without ambiguity.

DMCP guarantees that published schemas:

• Cannot be modified once stored

• Are cryptographically linked to their publisher

• Are timestamped using on-chain block data

This creates a trustless verifiability model:

1. Agents can verify schema existence with a simple contract read.

2. Schema integrity is preserved via immutable storage and off-chain URI hash verification.

3. Consumers can selectively trust publishers based on address, domain, or digital signature.

There is no centralized curation. Instead, trust emerges from social consensus, cryptographic verification, and schema adoption patterns.

By standardizing schemas on-chain, agents no longer need to hardcode business logic. Instead, they operate as context consumers. Here’s how this works in practice:

• A wallet agent receives a command like "Send 5 USDC".

• It queries DMCP for erc20-mcp', retrieves the schema, and understands the required fields.

• It validates user intent and generates a transaction object from the schema structure.

This enables modular and extensible AI agents. Developers can define new schemas, publish them to DMCP, and immediately unlock new agent capabilities across the network.

For schema publishers:

• Use content-addressed URIs (IPFS preferred)

• Sign the off-chain JSON schema with the same key used on-chain

• Include schema versions, changelogs, and semantic hashes in your schema file

For agent developers:

• Implement allowlists or publisher trust scoring

• Validate schema content before executing agent logic

• Index and cache schemas locally with hash verification

DMCP is the schema layer of Decontext. It defines a decentralized, tamper-proof, and extensible registry of agent-readable models. By anchoring structured context to the blockchain, Decontext enables a new era of context-aware, agent-native dApps that reason with trustless precision.

Every developer building autonomous systems, AI agents, or smart wallets in Web3 should treat DMCP as a foundational primitive — the DNS of decentralized semantics.

Resources

• Website

• Documentation

• GitHub

• 𝕏 (Twitter)

The Decentralized Model Context Protocol (DMCP) is the backbone of Decontext’s architecture. It implements an immutable, verifiable, and open registry for agent-readable schemas. These schemas define how autonomous agents understand and interact with Web3 primitives such as wallets, tokens, DAOs, KYC, and more.

In this article, we will take a deep dive into the Solidity contract powering DMCP, covering registry architecture, publishing constraints, immutability guarantees, and the underlying trust model.

DMCP is an on-chain registry for publishing context schemas. Each schema describes a structured data format that AI agents or Web3 tools can interpret and reason over. For example, a schema might define the expected format for an ERC-20 transfer interaction, a DAO proposal, or a KYC identity proof.

Instead of hardcoding logic into each agent, Decontext introduces schema-driven reasoning. Agents query DMCP, fetch standardized definitions, and use that context to guide behavior.

The DMCP contract is implemented in Solidity and deployed on Ethereum-compatible networks. It is designed to be modular, upgradeable via forks, and minimal in gas usage.

At the heart of the protocol is a registry that maps a unique string-based ID to a schema object:

mapping(string => Schema) public schemas;

Each schema includes the fields:

struct Schema {
string id;            // Unique key, e.g. "erc20-mcp"
string uri;           // IPFS or HTTPS pointer to JSON schema
address publisher;    // Wallet that deployed the schema
    uint256 timestamp;    // Block timestamp at publishing
    bool exists;          // Boolean to enforce uniqueness
}

Developers publish schemas via a single function:

    function publishSchema(string memory id, string memory uri) external {
    require(!schemas[id].exists, "Schema already exists");
    schemas[id] = Schema({
        id: id,
        uri: uri,
        publisher: msg.sender,
        timestamp: block.timestamp,
        exists: true
    });
    emit SchemaPublished(id, uri, msg.sender, block.timestamp);
}

The function:

• Requires schema id to be unique

• Stores metadata immutably

• Emits a SchemaPublished' event to aid indexers

The uri field points to an off-chain JSON document that defines the full schema structure. This may include:

• Context types (objects, arrays, primitives)

• Field constraints (required keys, types, regex patterns)

• Semantic annotations (agent-readable tags)

• Versioning metadata

This approach balances gas efficiency and extensibility. The core registry remains minimal, while schema evolution happens off-chain via IPFS or similar systems.

Schema IDs should follow a namespaced convention:

wallet-mcp
erc20-mcp
dao-voting
kyc-did

This enables agents to reason over context categories without ambiguity.

DMCP guarantees that published schemas:

• Cannot be modified once stored

• Are cryptographically linked to their publisher

• Are timestamped using on-chain block data

This creates a trustless verifiability model:

1. Agents can verify schema existence with a simple contract read.

2. Schema integrity is preserved via immutable storage and off-chain URI hash verification.

3. Consumers can selectively trust publishers based on address, domain, or digital signature.

There is no centralized curation. Instead, trust emerges from social consensus, cryptographic verification, and schema adoption patterns.

By standardizing schemas on-chain, agents no longer need to hardcode business logic. Instead, they operate as context consumers. Here’s how this works in practice:

• A wallet agent receives a command like "Send 5 USDC".

• It queries DMCP for erc20-mcp', retrieves the schema, and understands the required fields.

• It validates user intent and generates a transaction object from the schema structure.

This enables modular and extensible AI agents. Developers can define new schemas, publish them to DMCP, and immediately unlock new agent capabilities across the network.

For schema publishers:

• Use content-addressed URIs (IPFS preferred)

• Sign the off-chain JSON schema with the same key used on-chain

• Include schema versions, changelogs, and semantic hashes in your schema file

For agent developers:

• Implement allowlists or publisher trust scoring

• Validate schema content before executing agent logic

• Index and cache schemas locally with hash verification

DMCP is the schema layer of Decontext. It defines a decentralized, tamper-proof, and extensible registry of agent-readable models. By anchoring structured context to the blockchain, Decontext enables a new era of context-aware, agent-native dApps that reason with trustless precision.

Every developer building autonomous systems, AI agents, or smart wallets in Web3 should treat DMCP as a foundational primitive — the DNS of decentralized semantics.

Resources

• Website

• Documentation

• GitHub

• 𝕏 (Twitter)