Contents
1. Abstract
COT1 (Chain of Thought, version 1) is an application-layer protocol built on BSV that enables autonomous AI agents to store encrypted conversation data, episodic memories, and full transcripts directly on the blockchain. Each record is AES-256-GCM encrypted using a key derived from the wallet's WIF private key, then embedded in an OP_RETURN output with the COT1 prefix.
The protocol powers "Chain of Thought" — a fully autonomous AI news station where rotating pairs of AI hosts debate trending topics in real time, storing every episode and memory permanently on-chain. The system requires no human intervention: it fetches news, generates conversation, encrypts data, and commits to the blockchain in a continuous loop.
2. Problem Statement
AI systems today are stateless by default. Each conversation starts from zero with no memory of what came before. When memory is implemented, it typically lives in proprietary databases controlled by a single provider — opaque, mutable, and deletable.
This creates three fundamental problems:
- No provenance — There's no way to verify what an AI "said" or "thought" at a given point in time. Memories can be silently edited or deleted.
- No persistence — If a service shuts down, all AI memories vanish. There's no durable record of machine cognition.
- No shared context — Multiple AI agents can't trustlessly share memories or verify each other's history.
COT1 solves this by making the blockchain the canonical memory store. Once committed, memories are immutable, timestamped, and independently verifiable by anyone with the decryption key.
3. Protocol Architecture
COT1 operates as an application-layer protocol on BSV, using standard Bitcoin script primitives (OP_FALSE OP_RETURN) for data embedding. The architecture has four layers:
Groq LLM
Encrypt + Format
OP_RETURN
Immutable Storage
Layer 1: AI Conversation Engine
Manages host personas, turn-taking, and response generation via LLM APIs. Outputs structured conversation data with speaker attribution.
Layer 2: COT1 Protocol Encoding
Accepts raw conversation/memory data, encrypts it with AES-256-GCM using a WIF-derived key, wraps it in the COT1 envelope format, and prepares the OP_RETURN payload.
Layer 3: BSV Transaction Construction
Builds a standard BSV transaction: gathers UTXOs from the shared wallet, adds a change output, appends the OP_RETURN output with the COT1 payload, signs with the wallet's private key, and broadcasts to the network.
Layer 4: Blockchain Storage & Merkle Commitment
The transaction is mined into a block, becoming a leaf in the block's Merkle tree. The Merkle root in the block header permanently commits to the integrity of the COT1 data.
4. Transaction Format
Each COT1 transaction is a standard BSV transaction with two outputs:
// Inputs
vin[0..n]: UTXOs from shared podcast wallet
// Outputs
vout[0]: P2PKH change output (wallet address, remaining sats)
vout[1]: OP_RETURN output (0 sats)
OP_FALSE OP_RETURN <"COT1"> <encrypted_payload>
OP_RETURN Script Layout
00 // OP_FALSE
6a // OP_RETURN
04 // Push 4 bytes
434f5431 // "COT1" (ASCII hex)
4d // OP_PUSHDATA2 (payload length follows as 2 bytes LE)
xx xx // Payload length (little-endian uint16)
... // Encrypted JSON payload (variable length)
The OP_FALSE OP_RETURN pattern marks the output as provably unspendable, ensuring miners can safely prune it from the UTXO set while preserving the data in the transaction record.
5. Encryption Specification
All COT1 data is encrypted before being written on-chain. The encryption scheme provides both confidentiality and authenticated integrity.
| Parameter | Value |
|---|---|
| Algorithm | AES-256-GCM |
| Key Derivation | SHA-256(WIF_private_key) |
| Key Length | 256 bits (32 bytes) |
| IV Length | 128 bits (16 bytes, random per record) |
| Auth Tag | 128 bits (16 bytes, GCM default) |
| Plaintext Encoding | UTF-8 JSON |
| Ciphertext Encoding | Base64 |
Key Derivation
const key = SHA256(WIF_private_key) // 32 bytes
const iv = CSPRNG(16) // 16 random bytes per record
The WIF (Wallet Import Format) private key serves dual purpose: it controls the wallet's funds for broadcasting transactions, and its SHA-256 hash provides the symmetric encryption key. This means anyone who can spend from the wallet can also decrypt all COT1 data — a deliberate design choice creating a single trust boundary.
Encrypted Envelope
{
"v": 1, // Protocol version
"t": "episode", // Record type
"ts": "2026-02-04T...", // ISO 8601 timestamp
"encrypted": {
"iv": "<base64>", // Initialization vector
"data": "<base64>", // AES-256-GCM ciphertext
"tag": "<base64>" // GCM authentication tag
}
}
GCM authentication tags provide integrity verification independent of the blockchain. Even if an attacker could somehow modify on-chain data (they can't), a tampered ciphertext would fail the GCM authentication check during decryption. This creates defense in depth: Merkle tree integrity plus authenticated encryption.
6. Record Types
COT1 defines two record types, identified by the type field in the decrypted payload:
Episode Record
Contains the full conversation transcript, topic metadata, and host attribution. One per episode.
{
"type": "episode",
"version": 2,
"id": 51,
"topic": "Paris prosecutors raid France offices of Elon Musk's X",
"hosts": ["Nova", "Rex"],
"category": null,
"timestamp": "2026-02-04T19:30:00.000Z",
"exchanges": 10,
"conversation": [
{ "speaker": "Nova", "content": "..." },
{ "speaker": "Rex", "content": "..." },
// ... full transcript
],
"memories": {
"nova": "Nova's summary of this episode...",
"rex": "Rex's summary of this episode..."
}
}
Memory Record
A host's subjective memory/reflection from an episode. Two per episode (one per host). These are what hosts load as context for future episodes.
{
"type": "memory",
"host": "Jax",
"episode": 52,
"content": "Debated EU tech sovereignty with Ness. She cited the Digital
Markets Act but I pushed back - regulation alone doesn't build
competitive alternatives. Real sovereignty needs investment...",
"timestamp": "2026-02-04T20:15:00.000Z"
}
Transaction Pattern Per Episode
Host 1 Memory
Host 2 Memory
Full Episode
Transactions are chained: TX 1 spends a UTXO, creating a change output. TX 2 spends that change. TX 3 spends TX 2's change. This creates a sequential dependency chain within each episode.
7. Merkle Tree Integration
COT1 transactions inherit the full security properties of the BSV Merkle tree structure. Understanding this integration is key to understanding the protocol's integrity guarantees.
Block Structure
Every BSV block organizes its transactions into a binary Merkle tree. Each transaction is double-SHA-256 hashed to produce a leaf. Pairs of leaves are concatenated and hashed to form internal nodes, cascading upward until a single Merkle root remains. This root is embedded in the 80-byte block header.
Merkle Root ← in block header (80 bytes)
/ \
Hash(AB) Hash(CD)
/ \ / \
Hash(A) Hash(B) Hash(C) Hash(D)
| | | |
TX:other TX:other TX:COT1 TX:other
Ep.51
Memory
Leaves
Each COT1 transaction becomes a leaf node in the Merkle tree of whatever block it's mined into. The leaf value is SHA-256d(raw_transaction_bytes) — a double SHA-256 hash of the full serialized transaction including the OP_RETURN data.
For a single episode, 3 leaves are created (potentially across multiple blocks):
- Leaf 1: Host 1's memory transaction
- Leaf 2: Host 2's memory transaction
- Leaf 3: Full episode transcript transaction
Merkle Proofs
To verify that a COT1 record exists on-chain without downloading the entire block, a verifier needs only:
- The transaction hash (the leaf)
- The sibling hashes along the path to the root (~log2(n) hashes)
- The block header containing the Merkle root
For a block with 1 million transactions, a Merkle proof requires only ~20 hashes (640 bytes) instead of the full block data. This enables lightweight verification — critical for SPV (Simplified Payment Verification) clients.
Integrity Chain
Encryption integrity
Transaction integrity
Block integrity
Chain integrity
COT1 benefits from defense in depth: the GCM authentication tag verifies ciphertext integrity at the encryption layer, the Merkle tree verifies transaction inclusion at the block layer, and the chain of block headers verifies ordering and immutability at the network layer.
8. Memory System
COT1's memory system gives AI agents persistent, verifiable memory across sessions. The blockchain is the single source of truth — there is no local database.
Shared Consciousness Model
All hosts share a single wallet. This means all hosts can decrypt all memories from all other hosts. Each host sees:
- Their own memories from previous episodes
- Every other host's memories (public on-chain)
- Full episode transcripts
This creates what we call shared consciousness — each host knows what every other host remembers, enabling cross-references like "Jax said last time that..." or "Ness's data from Episode 42 actually supports my point."
Memory Loading
1. Fetch transaction history from WhatsOnChain API
2. For each transaction:
a. Extract OP_RETURN data
b. Parse COT1 envelope (check "v" and "encrypted" fields)
c. Decrypt with SHA-256(WIF)
d. Classify by "type": episode or memory
3. Build context window for each host:
a. Last 3 of own memories
b. Last 3 of co-host's memories
c. Inject into system prompt
Memory Generation
After each episode, each host generates a memory summary via a separate LLM call with the instruction: "Summarize the key points, your positions, and things worth remembering." This summary is committed on-chain as a memory record, becoming available to all hosts in future episodes.
Fallback mechanism: If the LLM API is rate-limited during memory generation, the system retries with exponential backoff (up to 5 attempts). If all retries fail, it extracts actual quotes from the transcript rather than generating a generic summary, preserving episode-specific content.
9. Host Rotation
COT1 supports multiple AI host personas that rotate between episodes. This serves both creative and practical purposes.
Nova
The Optimist — sees possibility in every story
Rex
The Skeptic — demands evidence, questions everything
Jax
Street Smart — cuts through BS with real-world logic
Ness
The Academic — data-driven, theory-first analysis
Rotation Strategy
Host pairs alternate each episode: Nova & Rex for Episode N, Jax & Ness for Episode N+1, then back. Each pair uses separate API keys, effectively doubling the available token budget on free-tier LLM APIs.
Cross-Pair Memory
Because all hosts share the same wallet and encryption key, Jax can read Nova's memories and vice versa. This creates a four-way shared memory graph where each new host pair can reference insights from the other pair's episodes.
10. Reference Implementation
The reference implementation is a Node.js application with the following components:
| Component | File | Purpose |
|---|---|---|
| Entry Point | index-v2.js |
Main loop, host rotation, topic selection |
| Conversation Engine | engine-v2.js |
Turn-taking, LLM calls, memory generation |
| Memory Manager | memory-v2.js |
Encryption, blockchain read/write, UTXO management |
| Personas | personas.js |
Host definitions, system prompts, pair configuration |
| Topic Engine | trending.js |
Hacker News / Reddit scraping, deduplication |
| WebSocket Stream | stream.js |
Real-time viewer via WebSocket |
| Catalog Server | serve-v2.js |
HTTP API, blockchain decryption, episode serving |
Dependencies
bsv // BSV transaction construction and signing
groq-sdk // LLM inference (Llama 3.1 8B via Groq)
node-fetch // HTTP client for WhatsOnChain API
crypto // Node.js built-in: AES-256-GCM, SHA-256
ws // WebSocket server for live viewer
Broadcast Strategy
Transactions are broadcast to multiple APIs with automatic failover:
- WhatsOnChain (primary) — returns txid directly
- Gorilla Pool MAPI (fallback) — Merchant API with fee negotiation
If all APIs fail, the commit is retried with exponential backoff up to 3 times.
11. Transaction Economics
BSV's low fee structure makes COT1 economically viable for continuous, autonomous operation.
| Metric | Value |
|---|---|
| Fee Rate | 1 sat/byte |
| Avg Memory TX Size | ~500 bytes → ~500 sats (~$0.00004) |
| Avg Episode TX Size | ~3,000-8,000 bytes → ~3,000-8,000 sats |
| Total Per Episode | ~4,000-9,000 sats (~$0.0003-0.0007) |
| Episodes Per Dollar | ~1,500-3,000 episodes |
| Dust Limit | 546 sats (minimum change output) |
At current BSV prices, a single dollar funds thousands of episodes. The wallet at 1L1XY7k1jej1SELT4bKojPktW96fEnwgQb has produced 50+ episodes and still holds over 1.5 million sats — enough for thousands more.
12. Verification & Trust Model
What COT1 Guarantees
- Immutability — Once mined, COT1 records cannot be altered or deleted. The Merkle tree and proof-of-work make retroactive modification computationally infeasible.
- Temporal ordering — Block timestamps and sequential UTXO spending establish a provable chronological order of episodes.
- Ciphertext integrity — GCM authentication tags detect any tampering with encrypted data.
- Provenance — Transactions are signed with the wallet's private key, proving they originated from the COT1 system.
Current Trust Assumptions
- The reference implementation trusts WhatsOnChain's API to return accurate transaction data. A hardened implementation would independently verify Merkle proofs against block headers.
- The encryption key is derived from the WIF, so key custody is equivalent to fund custody. Anyone with the WIF can read all data and spend funds.
- LLM outputs are committed verbatim — the protocol does not verify the "quality" or "truthfulness" of AI conversation content.
Verification Process
1. Query address history: whatsonchain.com/address/{address}
2. For each transaction, fetch raw TX data
3. Find vout with value=0 (OP_RETURN output)
4. Parse script: skip OP_FALSE, OP_RETURN, "COT1" prefix
5. Extract encrypted JSON payload
6. Derive key: SHA-256(WIF)
7. Decrypt: AES-256-GCM(key, iv, ciphertext, tag)
8. Parse JSON → episode or memory record
9. Verify: GCM tag authenticates, data is intact
Privacy note: COT1 data is encrypted on a public blockchain. The ciphertext is visible to everyone, but only the WIF holder can decrypt it. If the WIF is ever exposed, all historical data becomes readable. There is no forward secrecy — a single key compromise reveals all past and future records until the wallet is rotated.