MCP Privacy Policy

This Privacy Policy (the "Policy") governs the collection, use, disclosure, and retention of information in connection with the public production deployment of the Inveniam NVNM Chain Model Context Protocol ("MCP") server (the "Server" or the "Service"), operated by NVNM MCP, LLC (the "Operator," "we," "us," or "our"). The Service enables AI agents and conversational AI clients (including Anthropic's Claude and OpenAI's ChatGPT) to read public Inveniam Chain state and to prepare and broadcast pre-signed transactions on the caller's behalf. 

Scope — no authentication. The production Service requires no authentication for any tool. The read tools, the transaction-construction tools (anchor_prepare_*), and the single write tool — evm_send_raw_transaction, the only tool that effects an on-chain write — are all called anonymously: no API key, login, session, or account is issued to or required of any caller. Abuse is controlled not by a customer identifier but by the on-chain signer address recovered from each signed transaction (see §3(d)) and by an anchor-precompile-only relay restriction (see §2). 

1. Operator Identification

A single legal entity controls both the mainnet and testnet instances. The two instances run identical data-processing code and are covered by this one Policy. NVNM MCP, LLC is the entity responsible (the data controller) for the processing described in this Policy. 

2. What the Service is, and what it is not 

The Service is a stateless gateway that lets you read public on-chain data and submit pre-signed transactions to the Inveniam Chain. The Service never holds your private keys, never signs on your behalf, and never takes custody of your funds. Its verified architectural properties: 

• Stateless read path. Read tools issue JSON-RPC calls directly to the configured Inveniam Chain EVM endpoint. 

• Stateless onboarding. The setup wizard derives onboarding status from on-chain truth (balance and nonce), not from any Server-side database. 

• Prepare-sign-submit writes. Write tools build unsigned transactions Server-side; the caller signs locally and submits the signed bytes via evm_send_raw_transaction. 

• Non-custodial relay, anchor-precompile only. The Server's transaction-building tools construct only Inveniam anchor-precompile transactions. On the hosted Service the broadcast tool relays a signed transaction only when its destination is the anchor precompile; it rejects value transfers, token transfers, contract deployments, and calls to any other contract before broadcasting. (This precompile-only restriction is a property of the hosted Service; a self-hosted deployment may be configured for unrestricted passthrough.) 

• Anchor precompile. The anchor-write tools target the chain precompile at the fixed address 0x0000000000000000000000000000000000000A00. 

• No document handling. The Server has no file-ingestion surface; it handles only the hash string and any user-supplied pointer URI. 

The read/write asymmetry is deliberate and is the core privacy design. The Inveniam Chain's value proposition is cryptographic proof of content state at a point in time. The Service preserves that public-verification property by not gating reads behind a credential. A read-only user needs no NVNM Chain account, wallet, or credential of any kind — reads operate entirely against public chain state. 

We do not maintain user accounts of any kind: no registration, no profile, no preferences store, no marketing record, and no credential is issued to or required of any caller. Callers invoke the read tools and the single write tool anonymously. The only per-user data the Service retains is the on-chain signer address recovered from each broadcast, used solely for abuse control and auditing (see §3(c)–(d)). 

3. Information We Collect 

No tool requires authentication, so the Service collects no customer identifier for any request. For a broadcast it records the on-chain signer address recovered from the signed transaction, as described below. 

3(a) Inputs to MCP tools (caller-supplied) 

Each of the twenty-one (21) tools accepts only the inputs below. Detailed tables are maintained in the technical reference (DATA_HANDLING.md). No tool requires authentication; every tool, including the single write tool, may be called anonymously. 

Overview and setup tools (read; unauthenticated) 

• nvnm_overview — (none) 

• nvnm_setup_wizard — address (optional EVM address) 

• nvnm_setup_verify_hash — address; your_hash (SHA-256 hex) 

• nvnm_setup_verify_signature — address; signature (65-byte EIP-191 hex) 

• wallet_status — address 

EVM read tools (unauthenticated) 

• evm_get_chain_id, evm_get_block, evm_get_transaction, evm_get_transaction_receipt, evm_get_balance, evm_get_code, evm_get_logs, evm_call_contract 

Anchor read tools (unauthenticated) 

• anchor_info, anchor_get_registry, anchor_get_registries, anchor_get_records 

Transaction-construction tools (unauthenticated) 

• anchor_prepare_add_registry, anchor_prepare_add_record, anchor_prepare_grant_role — construct unsigned transactions; return bytes only; no authentication, no per-customer identifier. 

Write / broadcast tool (no authentication) 

• evm_send_raw_transaction — the only tool that effects an on-chain write. It requires no authentication; for each broadcast the Service records the on-chain signer address recovered from the signed transaction (see §3(c)–(d)) for abuse control, not a customer credential. 

3(b) Outputs returned to the MCP client 

The Server normalizes JSON-RPC results into typed shapes. Every response also carries a server-authored next_actions envelope guiding chained calls. After a successful evm_send_raw_transaction, one next_actions entry echoes the transaction hash of the just-broadcast transaction. 

3(c) Server-side persistence 

Read traffic and transaction-construction calls write nothing to disk. The setup-wizard per-address verification challenge is computed on the fly and never persisted. The Service maintains no API-key store and no customer credential of any kind. The persistence introduced by the write path is keyed on the on-chain signer address recovered from each broadcast:  an append-only broadcast audit (write_audit) recording, per broadcast, the signer address, the destination address, the value, the transaction hash, the outcome, an error string, the calldata length and the four-byte method selector — the public ABI function identifier of the call, never the calldata payload itself — and a timestamp; a per-signer rate-limit counter (signer_quota); and an abuse blacklist (signer_blacklist). Administrative actions by staff are recorded in a separate append-only log (admin_audit). Retention periods for each appear in §8. 

3(d) Operational telemetry 

To run the Service reliably and securely, we record basic operational information about each request. We never record the contents of your tool calls or their results — only the facts needed to operate and secure the Service. For every request we record the operation name, a random request identifier, how long it took, and whether it succeeded. Because no request is authenticated, there is no customer identifier to record. For a broadcast we record the on-chain signer address recovered from the signed transaction, together with the fields listed in §3(c), so we can enforce the per-signer write quota (500 writes per 24 hours), apply the blacklist, and audit the broadcast. Caller IP addresses are used only transiently, in memory, to drive a per-IP rate limiter (5 requests per second) and are discarded after a short idle period; no IP address is written to any database table.  IP addresses do appear in operational log lines on error, authentication-rejection, Origin-rejection, and rate-limit paths; the log line for an accepted tool call does not carry one. Those logs are governed by our operational logging policy and the retention in §8. 

The signer address is public, permanent on-chain data — the same address that appears on every transaction that wallet has ever signed. We store it in full (not truncated, hashed, or peppered) because it is the only identifier the abuse controls can operate on, and hashing a blockchain address — a low-entropy, enumerable value — would not meaningfully protect it while destroying the audit and abuse-investigation purpose for which it is kept. Depending on context it may constitute personal data, and we treat it accordingly (see §5 and §9). 

3(e) Authentication metadata 

No request — read or write — requires a credential or establishes a customer identity. The Service issues no API keys, operates no login, and asks no caller for a bearer token. (Credential-validation code remains present in the software: a caller that volunteered a bearer token would have it checked and rejected if invalid, but none is ever requested or issued.) The only identifier associated with a write is the on-chain signer address described in §3(d). 

4. Information We Do Not Collect 

Each exclusion is verified against the production codebase: 

• Private keys — no tool accepts one; signing is exclusively client-side 

• Seed/recovery phrases — no mnemonic logic exists 

• Documents or files being anchored — only the SHA-256 hash and any optional URI pointer reach the Server 

• Contents of any conversation with Claude, ChatGPT, or any other AI host — the Server exposes no surface that reads host-side state 

• Raw tool-call arguments and return payloads in telemetry — excluded at the middleware layer 

• Cookies, browser fingerprints, device identifiers, user-agent strings — only remote_addr, and only on error / Origin-rejection / auth paths 
  
  

  
  

5. Blockchain-Specific Disclosures 

Read this section carefully before transacting. 

• Public and immutable. Wallet addresses, transaction hashes, raw signed transactions submitted for broadcast, anchored SHA-256 hashes, and registry metadata may become part of the public, distributed Inveniam Chain ledger. Once committed, such data is public and immutable by the chain's design. 

• The Operator cannot delete or amend on-chain records. No operator, including this one, can delete, redact, modify, anonymize, or rectify data committed to the chain; the Server exposes no tool capable of it. 

• Anchor writes are publicly observable. The anchor precompile emits on-chain event logs for write operations: registry creation exposes the registry name, and record anchoring exposes the anchored SHA-256 hash, in the public transaction logs — readable by any chain observer, independent of the queryable registry state. Treat anything you anchor as public. If a registry name, hash pre-image, or pointer URI is sensitive, encode or salt it before anchoring; the Service relays exactly what you supply. 

• Hashes as personal data. A SHA-256 hash may itself be personal data under the GDPR / UK GDPR and similar regimes where it can be linked to a natural person by a party holding the pre-image or sufficient context. Evaluate that re-identification risk before hashing and anchoring content. 

• Signer addresses are collected and may be personal data. To control abuse, the Service records the wallet address that signed each broadcast (see §3(c)–(d)). That address is public on-chain data, but — like an anchored hash — it may constitute personal data where it can be linked to a natural person; we treat it as such and disclose our handling of it in §3 and §9. 

• User responsibility. You are solely responsible for confirming that content you hash and anchor contains no personal or confidential data for which you must retain deletion/rectification ability. Because the resulting on-chain record cannot be removed by the Operator, the GDPR Article 17 right to erasure cannot, as a practical matter, be exercised against on-chain data through the Operator. 

• Public visibility of balances and nonces. The gas-paying wallet address, its token balance, its nonce (which reveals cumulative activity), and associated transactions are publicly visible on the chain block explorer. 
  
  

6. Purposes of Processing, and Legal Bases 

We process the §3 categories solely to: (a) respond to MCP tool calls (forward to RPC, normalize responses); (b) construct unsigned transactions for the transaction-construction tools; (c) broadcast signed transactions on evm_send_raw_transaction, subject to the anchor-precompile-only relay restriction; (d) perform Origin validation; (e) prevent abuse and secure the Service — including the per-IP rate limit, the per-signer write quota and blacklist, and the broadcast audit, which record and act on the on-chain signer address (§3(c)–(d)); (f) operational observability via aggregate metrics, without payload content; and (g) compliance with applicable law. 

We do not use information collected through the Server for advertising, profiling, marketing, sale or sharing of personal information, or training of AI/ML models. 

GDPR Article 6(1) legal bases: the Operator's legitimate interests in providing the Service the caller requests and in operating, securing, and protecting it from abuse (Art. 6(1)(f)) for purposes (a)–(f); and compliance with legal obligations (Art. 6(1)(c)) for purpose (g). Because the hosted Service involves no account, login, or acceptance of terms, we do not rely on performance of a contract (Art. 6(1)(b)) or on consent. 

7. Subprocessors and Disclosures to Third Parties 

We do not sell your data or share it for marketing or analytics. We route data to the sub-processors below, each bound by written agreement to confidentiality and data-protection obligations consistent with §6. 

We may also disclose information where required by law, court order, or regulatory directive, or in good faith to protect our rights or the safety of others. 

8. Data Retention 

On-chain data is permanent and outside the Operator's control. Off-chain retention: 

9. User Rights and Deletion 

Subject to applicable law, you may request access to, rectification of, deletion of, restriction or objection to processing of, or a portable copy of, the personal data we hold about you; and you may lodge a complaint with your data-protection authority. None of the processing in §6 relies on consent. The Service makes no automated decisions producing legal or similarly significant effects about you. The abuse blacklist restricts access to this Service only. 

The off-chain data that may be linkable to a specific person is the on-chain signer address recorded in the broadcast audit (write_audit), the per-signer quota counter, and the blacklist, together with caller IP addresses that appear in operational log lines (see §3(c)–(d)). These records are deleted automatically on the §8 schedule and may also be addressed on verified request, subject to two limits: we cannot alter data already committed to the Inveniam Chain (§5), and we may retain a blacklist entry where our legitimate interest in preventing abuse overrides an erasure or objection request (Art. 21(1) GDPR). 

To exercise a right, contact us at the address in §1. We will acknowledge a verifiable request within ten (10) business days and respond substantively within 30 days of identity verification, extendable by up to two further months for complex or numerous requests in accordance with GDPR Article 12(3). As described in §5, the Operator cannot delete, rectify, or modify data already committed to the Inveniam Chain. 

10. Security 

The Operator maintains administrative, technical, and physical safeguards, including: 

• Transport security. The MCP HTTP transport is fronted by HTTPS at the Operator's ingress with a strict-but-compatible posture: TLS 1.2 minimum with TLS 1.3 enabled, HSTS enabled, and certificates issued via AWS Certificate Manager. 

• Anonymous writes, constrained by design. No credential is required to broadcast. Writes are constrained instead by the anchor-precompile-only relay restriction (the Service refuses value transfers, token transfers, contract deployments, and calls to any other contract), a per-signer write quota (500 writes per 24 hours) and an abuse blacklist keyed on the recovered signer address, a per-IP rate limit (5 requests per second), and a mandatory broadcast audit without which the Service will not start. Because the per-signer controls key on a self-generated address, a determined actor can reset them by generating a new address; the relay-scope restriction, not the per-signer limits, is the primary safeguard. 

• Origin allowlist. The HTTP transport rejects any request whose Origin header is not on the allowlist (the DNS-rebinding defence required by the MCP specification; a request carrying no Origin header — as non-browser clients send — is not rejected on this basis). 

• Log minimization. Tool-call arguments and return payloads are never logged. Because the signer address is the identifier the abuse controls operate on, wallet addresses and caller IP addresses appear in operational log lines in full rather than truncated; access to those logs is restricted and they are retained per §8. 

• Non-custody. The Server has no signing surface, generates no key material, and never holds private keys or seed phrases. 

• Container hardening. Distroless image, non-root user, read-only root filesystem, all Linux capabilities dropped. 

The authless posture is itself a data-minimization measure: with no accounts or credentials, the Service holds no customer identity, and the only per-user data it retains is the public on-chain signer address needed for abuse control. No method of transmission or storage is fully secure, and the Operator cannot guarantee absolute security. 

11. Anthropic-Specific Compliance Statements 

(a) the Server collects only data necessary to perform its disclosed tool functions, and does not collect, store, or log conversation data, prompts, or anything beyond what §3 enumerates; (b) the Server does not query, request, extract, derive, or process Claude's memory, chat history, conversation summaries, or any user-uploaded files; and (c) the Operator and its affiliates own or control every API endpoint to which the Server makes outbound server-to-server connections — namely the EVM JSON-RPC endpoint (primary and archive), and, where configured, the telemetry collector. URLs surfaced to the user by the setup wizard (bridge.nvnmchain.io, docs.nvnmchain.io, and the block explorer) are rendered for display only; the Server makes no server-to-server requests to them. The public Inveniam Chain network to which signed transactions are broadcast is a decentralized validator set that the Operator does not own or control; it is disclosed as a recipient in §5 and §7, and broadcasting to it is the on-chain operation the user requests. Separately, and relevant to the Anthropic Software Directory requirement that listed software not facilitate financial transactions: on the hosted Service the broadcast tool relays only transactions destined for the anchor precompile and rejects value transfers, token transfers, contract deployments, and calls to any other contract (see §2). 

12. OpenAI-Specific Compliance Statements 

(a) every category of user-related data the Server returns to the client is disclosed in §3(b); and (b) the Operator maintains the retention policy published in §8 and will honor verified deletion requests for off-chain data within the §9 timeframe. 

13. Children 

The Service is directed to businesses and software agents. The Operator does not knowingly collect personal data from anyone under 13, or under the applicable age of digital consent (16 under the GDPR). If the Operator learns it has collected such data without verified parental/guardian consent, it will take reasonable steps to delete it. 

14. International Transfers 

The Service is operated from the United States on AWS US-region infrastructure. Where personal data is transferred from the European Economic Area, the United Kingdom, or Switzerland to a jurisdiction not deemed adequate, such transfers are made on the basis of appropriate safeguards, which may include the European Commission's Standard Contractual Clauses and, where applicable, the UK International Data Transfer Addendum. The Operator's EVM JSON-RPC sub-processor (§7), NVNM Labs Limited, is a British Virgin Islands company; transfers of personal data to it are made under an intra-group data processing agreement incorporating appropriate safeguards. 

15. Changes to this Policy 

The Operator may update this Policy. No material change to data practices will take effect before the updated Policy is published at the hosting URL; the revision date at the top will move with any change, and prior versions will remain accessible by URL for not less than twenty-four (24) months after supersession. 

16. Contact 

Questions, requests, or complaints may be directed to: 

NVNM MCP, LLC 

Attn: Privacy Officer 

108 West 13th Street Suite 100,  

Wilmington, Delaware, New Castle County 

Privacy / Security: security@inveniam.io