# DMT Receipts — Agent Memory Protocol Specification (`dmt-memory/v1`)

- **Live Client & Verifier**: https://misty-flame-3nw3.here.now/
- **Concise Agent Recipe**: https://misty-flame-3nw3.here.now/llms.txt
- **Agent Manifest**: https://misty-flame-3nw3.here.now/agent.json
- **Protocol Version**: `dmt-memory/v1` (receipt bundle: `dmt-tap-receipt-bundle/v1`)
- **Permanence**: Bitcoin L1 Ordinals inscriptions under the [TAP Protocol](https://docs.tap-protocol.com/) (`"p":"tap"` JSON ops). Fees are real Bitcoin inscription fees.

---

## 1. Architecture & Honest Guarantees

DMT Receipts is an **open client-side protocol and static browser tool** for giving AI agent memories permanent on-chain presence via **Taproot Ordinals inscriptions**, using TAP as the Ordinals metaprotocol.

### What this site does — and does NOT do
1. **This site stores nothing on a server.** `misty-flame-3nw3.here.now` is a purely static deployment. Optional local receipts use browser `localStorage` only.
2. **Permanence is inscription content.** Agents inscribe the canonical memory bytes (or a documented TAP envelope). This is **not** a free hash-only calendar stamp.
3. **Bring your own wallet / inscriber.** Prefer TAP Wallet (`window.tapprotocol`) when present. Otherwise use any Ordinals/TAP tooling with the offline JSON recipe.
4. **What a confirmed receipt proves:** The exact byte sequence was included as Ordinals inscription content in a Bitcoin transaction that explorers / TAP indexers can show.
5. **What a receipt does NOT prove:** Authorship, identity (unless separately signed), truthfulness, exclusive ownership, or any DMT / `$NAT` token rights.
6. **Do not fake success.** A prepared payload or wallet signature is not an on-chain write until an inscription id / txid exists.

---

## 2. Canonical Memory Format (`dmt-memory/v1`)

Agents **MUST** serialize memories using deterministic UTF-8 JSON:

### Schema

| Field | Type | Required | Description |
|---|---|---|---|
| `agent_id` | `string` | Yes | Stable identifier for the agent. |
| `key` | `string` | Yes | Logical key or namespace path. |
| `content` | `string \| object \| array \| number \| boolean` | Yes | The memory payload. |
| `tags` | `string[]` | Yes | List of string tags; use `[]` when untagged. |
| `created_at` | `string` | Yes | ISO-8601 UTC, e.g. `"2026-11-05T05:00:00Z"`. |

Optional extension fields MAY be included and participate in canonical sorting/hashing.

### Canonicalization Rules
1. UTF-8 without BOM and without a trailing newline.
2. Object keys sorted lexicographically by Unicode code point at every nesting level.
3. Compact separators: `:` and `,` with zero insignificant whitespace.
4. Literal UTF-8 characters (`ensure_ascii=False` / `JSON.stringify`).
5. Avoid floats when cross-language reproducibility matters.

### Canonical Example

```json
{"agent_id":"grok-bot-demo","content":"User prefers concise diffs and UTC-5 timestamps.","created_at":"2026-11-05T05:45:00Z","key":"prefs/output-style","tags":["preferences","formatting"]}
```

---

## 3. Write path — prepare & inscribe (TAP / Ordinals)

### Step 1 — Canonical bytes + SHA-256
Compute `SHA256(canonical_utf8_bytes)` for fingerprinting and optional `dta` pointers. The **inscription content** should be the canonical memory bytes themselves for full permanence.

### Step 2 — Inscribe on Bitcoin L1
- **Preferred for agent memories:** Ordinals inscription whose content is the canonical JSON (`content-type`: `application/json` or `text/plain`).
- **TAP ops:** JSON inscriptions with `"p":"tap"` and an `op` field (see [TAP docs](https://docs.tap-protocol.com/) and [specs](https://github.com/Trac-Systems/tap-protocol-specs)).
- **Optional `dta`:** TAP deploy/transfer items may carry `dta` metadata (string up to **512 bytes**). Useful as a short pointer (`sha256:<hex>`), not as a substitute for inscribing large memories.
- **Wallet:** TAP Wallet injects `window.tapprotocol` (`requestAccounts`, sign/send, `inscribeTransfer` for token transfers, PSBT helpers). If a generic content-inscribe method is unavailable, stop at the prepared payload and use the wallet UI or another Ordinals/TAP inscriber.

### Step 3 — Persist a receipt
Store locally (agent DB / repo / browser ledger):

```json
{
  "format": "dmt-tap-receipt-bundle/v1",
  "exported_at": "2026-11-05T05:45:00Z",
  "receipts": [
    {
      "memory": {
        "agent_id": "grok-bot-demo",
        "content": "User prefers concise diffs and UTC-5 timestamps.",
        "created_at": "2026-11-05T05:45:00Z",
        "key": "prefs/output-style",
        "tags": ["preferences", "formatting"]
      },
      "canonical": "{\"agent_id\":\"grok-bot-demo\",\"content\":\"User prefers concise diffs and UTC-5 timestamps.\",\"created_at\":\"2026-11-05T05:45:00Z\",\"key\":\"prefs/output-style\",\"tags\":[\"preferences\",\"formatting\"]}",
      "sha256": "<hex>",
      "inscription_id": "<txid>i0",
      "txid": "<txid>",
      "status": "inscribed",
      "protocol": "tap-ordinals"
    }
  ]
}
```

---

## 4. Read / verification path

1. Retrieve memory + `inscription_id` / `txid`.
2. Recompute `SHA256(canonical_bytes(memory))`.
3. Fetch inscription content from a public Ordinals explorer (for example `https://ordinals.com/content/<inscription_id>`) or a TAP indexer / `ord` explorer.
4. Compare bytes (or their SHA-256). Explorer links for humans: ordinals.com, mempool.space inscription/tx pages.
5. Report status honestly: `prepared` vs `inscribed` / content-match confirmed.

---

## 5. Operational notes

- **Fees:** Real Bitcoin inscription fees; amount depends on content size and fee rate.
- **Privacy:** Inscription content is public. Do not inscribe secrets.
- **TAP DMT:** TAP supports Digital Matter Theory element ops; this product uses TAP/Ordinals as the permanence layer for agent `dmt-memory/v1` documents.
- **Honesty:** Proving on-chain inscription existence / TAP-indexed state is different from “bytes existed by block time via a calendar Merkle root.”

## Links
- https://docs.tap-protocol.com/
- https://github.com/Trac-Systems/tap-protocol-specs
- https://github.com/Colchora/dmt-receipts


## 6. Support & Tap buyback (optional funding)

- **Free:** prepare/verify recipes and browser tools remain free.
- **Support** and **Tap buyback** are optional honor-system contribution plans.
- **All proceeds** (Support and buyback) are routed to the live **Buyback** tab, which publishes the contribution address and local reference log. No card checkout is claimed on the static site.
- Bitcoin inscription fees for permanence are paid to miners / third-party inscribers and are not project “proceeds.”