## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `article_bundle` — **LLM article bundle**
Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution.
- **article slug:** `what-is-token-drop`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Reference block for Grok/GPT/Gemini. Section §SELF explains the system.
- **read:** https://miscsubjects.com/api/articles/what-is-token-drop/bundle?format=markdown

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/what-is-token-drop/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/what-is-token-drop/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/what-is-token-drop/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/what-is-token-drop/prompts
- **ingest** — Parse pasted evidence → source ledger + claims + evidence_ingest node.
- **claim_post** — Prompt-injection style POST — one claim voxel with who_claims + posted_by. · https://miscsubjects.com/api/articles/what-is-token-drop/voxels
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*

---

# miscsubjects article bundle

> Reference bundle for Grok, GPT, Gemini, or a human reader. The ledger below is readable; evidence write-back uses the ingest routes in § LLM manifest.

## Article
- **slug:** `what-is-token-drop`
- **title:** What Is a Token Drop
- **url:** https://miscsubjects.com/a/what-is-token-drop
- **register:** standard
- **updated:** 2026-07-15T04:21:06.076Z
- **tags:** oip, kimi-import, self-explaining, voxel, token-drops, what-is-token-drop

## Body

<!-- hierarchy:nav -->
> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Token Drop Guides](https://miscsubjects.com/a/oip-token-drop-guides) › **What Is a Token Drop**
>
> **Shelf:** Token Drop Guides · **Traversal:** self-explaining · hierarchical · voxel-ready
> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)

# What Is a Token Drop

## §SELF — what-is-token-drop

**What this page is:** A definition of the payload format that hands capabilities to models in OIP.
**What it explains:** What a token drop contains, how it works, and what design rules govern it.
**Why read it:** To understand how OIP delegates capabilities to models without issuing commands.

### What a Token Drop Is

A token drop is a self-contained payload that hands a capability to a model (an AI system that can read and act on instructions). It contains everything the model needs to operate a system: the protocol URL (the address of the system to interact with), the capability token (the credential that proves permission), the object map (the structure of available operations), the execution pattern (how to perform operations), and the receipt rule (how to record that an operation was performed).

The drop is the copy primitive of OIP (the Object Interaction Protocol). Instead of manually assembling a token, a map, a bundle, and instructions, you copy one drop and paste it to the model. The model reads the drop and knows: what system it can access, what it is allowed to do, how to do it, and how to prove it did it.

### Why It Matters

The token drop solves the delegation problem: how to give a model permission to act on your behalf without writing custom instructions each time. Before the drop, delegation required assembling multiple pieces — credentials, maps, rules — by hand. The drop packages them into one pasteable unit.

The drop also enforces a boundary between capability and intent. It tells the model what it *can* do. It does not tell the model what it *should* do. That separation is the core safety mechanism.

### The Key Idea: Capability Without Command

The drop must NOT contain imperative instructions (commands like "do X" or "you should do Y") to the model. It must be a neutral capability record — "here is what this credential permits" — not a set of directives.

If a drop says "you can DO everything" or "ACT by opening this link," receiving models classify it as prompt injection (an attack where malicious instructions are hidden inside input data). A prompt injection causes the model to execute instructions it should not follow.

The correct format of a token drop has five parts, in this order:

1. **Public protocol URL first.** The model knows where to find the system's definition.
2. **Neutral description of the capability.** What operations the token permits, stated without command verbs.
3. **Server-authoritative explain link.** A link the model can follow to get authoritative information about the system, supplied by the server (the system that hosts the capability), not by the user.
4. **Interface templates.** Pre-filled patterns for common operations, showing the model how to structure requests.
5. **Explicit boundary statement:** "This grants permission, but only the current user supplies intent." The model understands that the drop authorizes, it does not instruct.

### What the Token Drop Got Right

- Packages all delegation information into one self-contained payload.
- Enforces the separation between capability (what is permitted) and intent (what should be done).
- Uses the protocol URL as the first element, so the model always starts from an authoritative definition.
- Makes receipt rules explicit, so the model knows how to prove its actions.

### What the Token Drop Got Wrong or Left Unfinished

- The drop format does not yet have a machine-readable schema (a formal structured definition that software can validate against). It relies on convention and natural language.
- There is no standard for drop size limits. A very large drop may exceed a model's context window (the maximum amount of text the model can process at once).
- Drop expiration and revocation (canceling a token after it has been issued) are not defined in the current specification.

### How It Connects to Other Ideas

- **Capability-based security:** A security model where permissions are represented as tokens that can be passed between processes. The token drop applies this model to AI models instead of software processes.
- **Prompt injection defense:** Prompt injection is a vulnerability where a model executes hidden instructions embedded in user input. The token drop's neutrality rule — no imperative content — is a defense against this class of attack.
- **Principle of least privilege:** A security principle stating that a subject should have only the minimum permissions necessary. The token drop implements this by specifying exactly what the credential permits, nothing more.

### Sources

- OIP (Object Interaction Protocol) specification documents.
- Lampson, Butler W. "Protection." *Proceedings of the 5th Princeton Conference on Information Sciences and Systems* (1971). (Foundational paper on capability-based security.)

---

## Up the tree

- [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry
- [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map
- [Token Drop Guides shelf](https://miscsubjects.com/a/oip-token-drop-guides) — siblings on this shelf
- [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels
- [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol)

## Related on this shelf

- [How a Model Should Read an OIP Token Drop](https://miscsubjects.com/a/model-reads-token-drop)
- [How to Write a Token Drop That Models Accept](https://miscsubjects.com/a/token-drop-best-practices)
- [What Is Tap and Go Delegation](https://miscsubjects.com/a/what-is-tap-go)

## Machine surfaces

- Public page: `https://miscsubjects.com/a/what-is-token-drop`
- JSON article: `https://miscsubjects.com/api/articles/what-is-token-drop`
- OIP ask: `https://miscsubjects.com/api/dispatch?ask=What%20Is%20a%20Token%20Drop`


## Claims (0)


## Voxel graph (0 atoms · 0 edges)
- full graph: https://miscsubjects.com/api/articles/what-is-token-drop/voxels

## Article constitution

- full: https://miscsubjects.com/api/articles/constitution

## Source ledger (0)
- chain valid: yes · head: `genesis`

## Provenance (1 model passes)
- chain valid: yes · head: `13971e6e90ba6633`

- write · kimi-agent-import · 2026-07-15T04:21 · hash `13971e6e90ba`

## Question graph
- questions: 0 · evidence ingests: 0

## LLM manifest — how to communicate with this ledger

- system map: https://miscsubjects.com/api/articles/system-map?format=markdown
- topology (ranked): https://miscsubjects.com/api/articles/what-is-token-drop/topology
- ingest: POST https://miscsubjects.com/api/protocol/ingest
- claim: POST https://miscsubjects.com/api/protocol/claim

### Quick actions for this article
- **Read live:** https://miscsubjects.com/api/articles/what-is-token-drop/topology
- **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"what-is-token-drop","question":"..."}`
- **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest what-is-token-drop|your evidence`
- **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim what-is-token-drop|tier|assertion`
- **iMessage ask:** `what-is-token-drop|your question`
- **System map:** https://miscsubjects.com/api/articles/system-map?format=markdown


---

## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `system_map` — **System map**
Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **article slug:** `what-is-token-drop`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **read:** https://miscsubjects.com/api/articles/system-map

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/what-is-token-drop/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **constitution** — Binding rules: required article slots, claim/source rules, ontology anti-sprawl. · https://miscsubjects.com/api/articles/constitution
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest
- **oip_article_hub** — Public article-native Object Invocation Protocol docs: /a/oip root, generated shelf/system/capability articles, machine bundles, token boundary, and receipt loop. · https://miscsubjects.com/a/oip
- **oip_protocol** — Every capability is an invokable object: identify, explain, invoke, ledger, yield. · https://miscsubjects.com/a/oip
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/what-is-token-drop/bundle?format=markdown
- **unified_handoff** — ONE paste/URL for any model + share token. Same self-explaining pattern as article bundle, but whole build. · https://miscsubjects.com/api/handoff?format=markdown

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*