Core Concepts

1. 🔄 Model Context Protocol (MCP)

What is MCP?

Model Context Protocol (MCP) is a structured interface and data model that enables Large Language Models (LLMs) to consume user-specific context from decentralized sources in a secure, verifiable, and modular manner.

📚 Reference Documentation: docs.modelcontext.org

MCP acts as a protocol abstraction layer bridging:

• 🧾 Context Providers: Wallets, smart contracts, decentralized identity (DIDs), DAOs, on-chain storage, etc.

• 🤖 Context Consumers: LLMs, AI agents, autonomous assistants, and context-driven bots.

MCP defines how verified data travels from Web3 infrastructure into language models without compromising user sovereignty or privacy.

---

What is MCP3?

MCP3 is the third iteration of the Model Context Protocol, designed specifically to interface with modern agentic LLMs and privacy-preserving identity standards. MCP3 introduces Machine Context Objects (MCOs) as cryptographically signed containers of structured, scoped, and optionally encrypted user context.

---

✅ What MCP Enables (with Web3 Integrations)

MCP leverages best-in-class Web3 technologies to provide end-to-end verifiable context handling:

Capability	Description	Web3 Technology Example
Context Negotiation	Determine what context the model can access based on user-granted scopes and roles.	🏷️ EIP-712, ERC-725, DIDs
Context Injection	Insert structured, real-time data into prompts, API calls, or system messages.	🌐 The Graph for on-chain indexing, ENS for identity
Context Provenance	Establish origin, authenticity, and timestamp of context with proofs.	🔐 Chainlink (oracle attestations), Ceramic, ZKPs
Context Storage	Persist and optionally share encrypted context objects.	🗂️ Arweave, IPFS, Lit Protocol
Context Retrieval	Query historical or ephemeral context based on user or session.	🔁 Ceramic IDX, Farcaster, Lens Protocol

MCP ensures that LLMs and autonomous agents never operate on unverifiable or non-consensual data, fulfilling a zero-trust and user-centric model of context-aware computation.

---

2. 🧠 What is “Context”?

In MCP, context refers to any dynamic or persistent data that influences the behavior, personalization, or output of an AI model or agent. Context provides the model with verifiable knowledge about the user, their state, identity, and environment.

---

🧾 Types of Context

Type	Description	Web3 Source Examples
User Identity	Wallet addresses, DIDs, ENS names	🆔 DID:ETHR, ENS, Ceramic IDX
Access Rights	Ownership of NFTs, DAO memberships, POAPs	🗳 Snapshot, ERC-721, ERC-1155, Guild.xyz
Behavioral History	Transaction logs, voting records, participation streaks	📜 Etherscan, The Graph, DAOhaus, Tally
External Data Feeds	Live oracles for prices, identity attestations, off-chain inputs	🔗 Chainlink, API3, UMA, Space and Time
Social Graph	Follower graphs, profile metadata	🌐 Farcaster, Lens Protocol, CyberConnect

---

🧩 Nature of Context

Category	Description	Example
Static	Persistent attributes	ENS name, DAO role
Dynamic	Frequently changing values	Wallet balance, proposal count
Permissioned	Requires explicit user consent or scoped access	Encrypted MCO field, POAP claim

---

🔐 How MCP Handles Context

MCP ensures context is:

• Scoped: Models only see what they are authorized to access (e.g., read.profile, read.dao).

• Signed: All context is verified at the source using EIP-712 signatures or ZK-based attestations.

• Composable: Context is aggregated from multiple Web3 protocols and abstracted into a Machine Context Object (MCO).

Each context field can optionally be:

• 🔒 Encrypted: Using Lit Protocol or client-side encryption.

• 📦 Stored: On decentralized storage like IPFS or Arweave.

• 🧾 Attested: With proofs from Chainlink, Ceramic, or custom ZK-proofs.

---

3. Web3 Integration Layers

Layer	Description	Role in MCP3
Wallets	MetaMask, WalletConnect, Frame	User authentication and signature-based consent
DIDs	Decentralized Identifiers (DID:ETHR, DID:PKH)	Persistent identity across chains and apps
Smart Contracts	EVM-based contracts, DAO governance	Source of on-chain data (roles, proposals, ownership)
Storage	IPFS, Arweave, Ceramic	Persistent storage of user-defined context
ZK Proofs	zk-SNARKs, zkKYC	Privacy-preserving context validation

---

4. MCP Context Object (MCO)

All contextual data is encapsulated in a standardized object called the MCP Context Object (MCO).

Example (simplified):

{
    "subject": "did:ethr:0x123...",
    "timestamp": 1728323900,
    "permissions": ["read.profile", "read.dao_membership"],
    "data": {
        "wallet": {
            "address": "0x123...",
            "tokens": ["$MCP3", "DAI"],
            "nft_count": 4
        },
        "dao": {
            "member_of": ["MetaDAO", "GovAlpha"],
            "voting_history": ["proposal_45", "proposal_47"]
        }
    },
    "proof": {
        "type": "EIP712Signature",
        "signature": "0xabc123..."
    }
}

This object is passed to the LLM via an MCP-compliant context bridge, allowing the model to reason with real-world, decentralized context securely and transparently.

---

5. Benefits of MCP3 Approach

• 🔐 Privacy by Design: Users selectively share context via signature or ZK proofs.

• 🧩 Composable AI Agents: Agents can plug into multiple context sources.

• ⚙️ Verifiable Reasoning: Every piece of context can be traced and validated.

• 🌐 Cross-chain Compatible: MCP3 is blockchain-agnostic and interoperable.

==========

🏗️ Architecture Overview

High-Level System Architecture

MCP3 is built on three pillars:

1. Context Providers (Web3 sources)

2. MCP Protocol Layer (context abstraction + validation)

3. LLM Agent Layer (context-consuming intelligent systems)

These are connected through a Context Bridge, enabling LLMs to access user-specific, permissioned data with cryptographic integrity.

---

Key Components

1. User Wallet & DID Resolver: Identity root, signs permissions, integrates via WalletConnect, MetaMask, or DID-based auth.

2. Smart Contract Layer: Provides on-chain data (DAO memberships, governance, tokens).

3. Context Gateway (MCP Engine): Aggregates, normalizes, and signs data into the MCO. Handles permission negotiation.

4. Storage Layer (optional): IPFS / Ceramic / Arweave for semi-static context (profiles, settings, chats).

5. LLM Runtime / Agent Layer: Receives structured MCO objects for fine-tuned responses. Interfaces via chatbot UIs, CLI tools, or embedded assistants.