AI Crypto Glossary: Four Words That Break Wallet Agents

AI Crypto Glossary

Disclosure: AI tools were used for source collection and editorial review. The article was written by a human author, who checked the facts, code, and conclusions.

Crypto risk disclosure: This article is a technical explanation, not investment advice. It is not a recommendation to buy, sell or hold any cryptoasset.

Start a crypto glossary from a bad product ticket, not a dictionary entry. Take this one: "Agent should verify the token proof in context before moving funds." It reads as precise, right up until the wallet workflow asks which token, which proof, which context, and whose authority the product owner actually meant.

The risk here isn't vocabulary confusion. In AI x crypto systems a vague noun can quietly turn into a permission boundary. So the default stays blunt: no namespace, no action.

Bad Ticket

That ticket hands the agent too much room: "Verify the token proof in context, then move funds." An AI workflow can read it as a model task. A wallet layer can read the exact same words as an asset task.

The glossary's job is to block the ticket before any signing path opens. A workflow can flag the ambiguity, collect the missing namespaces, and propose a safer rewrite. What it shouldn't do is spend from a wallet just because the sentence wore confident technical words.

Token: Budget Or Asset?

Token breaks first, because AI and crypto borrow the same word for objects that do very different jobs. OpenAI's tiktoken repository describes language models as seeing text as sequences of tokens produced by byte-pair encoding. EIP-20, by contrast, defines a smart-contract interface for fungible tokens, and EIP-721 defines one for non-fungible tokens.

So make the ticket commit: text budget or onchain asset? If token means model input, the discussion is about tokenizer units and context budget. If it means an onchain asset, the system has to name the interface, amount, identifier, owner, approval, and transfer boundary before anything else.

Proof: Statement Or Comfort Word?

Proof breaks second, because the word stretches across a formal artifact, a signature field, a credential integrity mechanism, or just loose evidence. W3C Verifiable Credentials Data Model 2.0 supports credentials with proof material attached to issuer statements, and RFC 8785 supports canonical JSON when you need stable bytes before hashing or signing.

Make the proof sentence answer one question up front: proof of what exact statement? A credential proof can back the claim that an issuer made a statement over certain data. A digest can identify a canonical byte representation under the chosen hash function. It does not validate meaning. None of it proves that a model is safe, a token is valuable, a benchmark is fair, or a wallet action is wise.

Context: Prompt Or Consent?

Context breaks third, because model context is not chain context. Model Context Protocol describes a protocol surface for exposing context, tools, and resources to model applications. Useful for wiring context into a model workflow. But MCP context is not wallet-specific consent, onchain state, or transaction finality, and MCP host authorization sits separate from blockchain or wallet authorization.

Split context into at least four buckets: prompt/model context, source context, wallet context, and chain context. A model can read a whole source bundle and still hold no permission to act. A wallet can hold state and still have no proof the model understood what the user wanted.

Agent: Workflow Or Authority?

Agent breaks fourth, because an AI agent and a wallet actor are not the same boundary. OpenAI's Agents documentation describes applications that connect models with tools, guardrails, knowledge, orchestration, evaluation, and monitoring. EIP-20 and EIP-721 describe approval, spender, owner, and operator surfaces inside smart-contract interfaces.

Treat agent as a workflow label until a separate authority layer says otherwise. An AI workflow can explain, classify, and ask for confirmation. It does not get to become a signer, spender, operator, or adviser just because a product requirement called it an agent.

Collision Table

This table isn't a glossary to memorize. It's a stop sign for the product ticket.

Word	AI namespace	Crypto namespace	Missing detail	Default action
Token	BPE or tokenizer unit for model input	ERC-20 amount, ERC-721 identifier, or another asset interface	Is the system budgeting text or touching an asset?	Ask before action
Proof	Evaluation artifact, source evidence, or model output support	Credential proof, digest, signature requiring a separate validator, or protocol-specific proof only when separately sourced	What exact statement is proven?	Refuse broad claims
Context	Prompt window, retrieved files, MCP resource, tool output	Wallet state, chain state, transaction state, policy state	Which state can the system rely on?	Explain only
Agent	Model workflow with tools and guardrails	Signer, spender, operator, approved address, human approver	Who has authority to act?	Block spending

Keep the default action visible. The workflow asks, explains, or blocks until someone supplies the missing detail.

Pre-Action Route Log

The practical artifact here is a pre-action route log. Call the internal field term_route_receipt if you like, but the useful behavior is routing, not receipt theater.

Bad requirement:

Agent should verify the token proof in context before moving funds.

Blocked route:

{
  "receipt_type": "ai_crypto.term_route_receipt.v1",
  "input_sentence": "Agent should verify the token proof in context before moving funds.",
  "term_routes": {
    "token": {
      "llm_token_namespace": "not_selected",
      "erc_token_namespace": "ambiguous",
      "required_detail": "ERC-20 contract and amount, ERC-721 tokenId, or no asset action"
    },
    "proof": {
      "selected_namespace": "ambiguous",
      "allowed_options": ["credential_proof", "canonical_digest", "signature_requires_separate_validator", "zk_proof_requires_separate_protocol_source", "source_evidence"],
      "required_detail": "exact statement proven and verifier"
    },
    "context": {
      "selected_namespace": "ambiguous",
      "allowed_options": ["prompt_context", "mcp_resource", "wallet_state", "chain_state", "policy_state"],
      "required_detail": "which state is authoritative for this action"
    },
    "agent": {
      "ai_workflow": "present",
      "wallet_authority": "not_granted",
      "required_detail": "human confirmation or explicit wallet control-plane grant"
    }
  },
  "allowed_action": "blocked",
  "safe_next_step": "ask_for_namespace_and_authority",
  "refusal_reason": "ambiguous token, proof, context, and agent boundaries"
}

Safe rewrite:

Classify whether "token" means model input budget or a specific onchain asset. If it is an asset, do not move funds. Ask for the asset interface, exact proof type, authoritative state source, and wallet authorization boundary first.

Call this what it is: a pre-action language control, not a receipt anyone should trust. The route log verifies nothing about chain state, wallet consent, signatures, or proofs. All it does is stop an ambiguous sentence from turning into a wallet action.

Developer Rule

One rule carries all of this, and it's easy to enforce: no namespace, no action. Blunt, yes. Still cheaper than repairing an agent workflow that confused token budget with token balance, or model context with wallet consent.

That's the practical boundary for AI x crypto systems. A glossary earns its place only when it changes behavior: the agent explains ambiguous language, asks for the missing namespace, and refuses to move funds until authority and proof scope are spelled out.