Dieses Wochenende habe ich einen MCP-Server für ein Bitcoin-Wallet zusammengestellt: Tools, die KI-Agenten über das Model Context Protocol aufrufen können. Das [Repo](https://github.com/markmhendrickson/mcp-server-bitcoin) stellt 93 Tools auf Layer 1 und Layer 2 bereit. Eine Mnemonik steuert beide.

Zuvor war ich General Manager von [Leather](https://leather.io), einer Krypto-Wallet, die auch Bitcoin und Stacks unterstützt. Bei Leather habe ich gesehen, dass selbstverwahrende Wallets mit Blick auf den Menschen vor allem Menschen erreichten, die bereit waren, die Aufmerksamkeit und Komplexität in sich aufzunehmen (z. B. Degens und Entwickler). Das bedeutete wichtige Hygiene, Gebührenbewusstsein, Konfirmationsabläufe und so weiter. Die kognitive Belastung hielt den tatsächlich adressierbaren Markt eng.

Agenten-Wallets ändern das. Wenn die primäre Schnittstelle aus Agenten besteht, die innerhalb der Richtlinie argumentieren und ausführen, genehmigt der Benutzer nur das, was wichtig ist. Die Reibung sinkt und die Gruppe der Menschen, die praktisch ihre eigenen Schlüssel halten können, wächst.

Gleiche zwei Ketten. Andere Oberfläche.

## Was der Server offenlegt (L1 und L2 in einer Oberfläche)

Der Server ist ein einzelner MCP-Prozess. Clients senden Toolnamen und JSON-Argumente über stdio und erhalten strukturierte Ergebnisse zurück. Zerstörerische Aktionen (Senden, Signieren und Senden, Bereitstellen) unterstützen „dry_run“ und senden standardmäßig nicht. Der Server gibt niemals Schlüssel oder Mnemoniken zurück.

### Schicht 1 (Bitcoin)

**Kern-Bitcoin:**

- Adressableitung für P2PKH, P2SH-P2WPKH, P2WPKH und P2TR mit öffentlichen Schlüsseln und Pfaden.
- Konten mit Salden pro Adresstyp ([mempool.space](https://mempool.space) für UTXO-Daten); Wallet-Guthaben und BTC-Preise (USD, EUR).
- Einzel- und Mehrfachempfängersendungen (Betrag in BTC oder EUR); Vorschau der Überweisung mit Kostenvoranschlag vor dem Senden.
- Sweep (maximal senden) und UTXO-Konsolidierung.
- PSBT-Signierung, Dekodierung und Batch-Signierung; Signieren und Verifizieren von Nachrichten (ECDSA Legacy und BIP-322).
- Gebührenstufen von mempool.space und Gebührenschätzung nach Ein-/Ausgabeanzahl und Adresstyp.
- UTXO-Auflistung mit Filtern (Adresstyp, Mindestwert, nur bestätigt) und Details pro UTXO.

**Ordinalzahlen und Inschriften:**

- Inschriften mit Paginierung auflisten; Details zur Inschrift (Genese, Inhaltstyp, Sat-Ordinalzahl, Seltenheit, Ort).
- Senden Sie Inschriften (vollständiges UTXO oder aufgeteilt, sodass nur der Sat-Bereich der Inschrift an den Empfänger geht).
- Ordinalzahlen aus gemischten UTXOs extrahieren; BTC aus der Ordinaladresse wiederherstellen (UTXOs ohne Inschrift durchsuchen); Stellen Sie Ordnungszahlen, die an der Zahlungsadresse gelandet sind, wieder an die Taproot-Adresse zurück.
- Erstellen Sie Einzel- oder Sammelinschriften mit Schätzungen der Commit-/Reveal-Gebühren.

**Transaktions- und Wallet-Management:**

- Transaktionsverlauf für BTC und Stacks; Status für einen einzelnen Sender.
- Beschleunigen Sie ausstehende BTC über RBF; Abbrechen bis BTC (RBF-Send-to-self) aussteht.
- Netzwerkkonfiguration und API-Endpunkte; Mainnet/Testnet wechseln; Benutzerdefiniertes Netzwerk hinzufügen.
- Listen Sie alle unterstützten Werkzeugnamen und -beschreibungen auf.

**Ledger (Bitcoin-App):**

- Holen Sie sich BTC-Adressen von einem verbundenen [Ledger](https://www.ledger.com)-Gerät.
- Signieren Sie PSBT mit der Ledger Bitcoin-App.

### Schicht 2 (Stapel)

Die gleiche Mnemonik leitet Stacks-Schlüssel ab (Pfad „m/44“/5757“/0“/0/0“). [Hiro](https://hiro.so) Stacks-API für Kettendaten und Broadcasting.

**Stapel:**

- Adressen und öffentliche Schlüssel; Konten mit STX-Saldo, gesperrten Beträgen, Nonces.
- Guthaben einschließlich fungibler und nicht fungibler Token.
- STX-Übertragung (Micro-STX) mit optionalem Memo; Vorschau der Überweisung mit Gebühren- und Kontostandsprüfung.
- SIP-10-fungible und SIP-9-NFT-Übertragungen über Vertragsanrufe.
- Klarheit: öffentliche Funktion aufrufen, Vertrag bereitstellen, schreibgeschützter Aufruf.
- Signieren Sie serialisierte Stacks tx (SIP-30), signieren Sie Nachrichten, signieren Sie strukturierte SIP-018-Daten; Nonce- und Gebührenschätzung.
- On-Chain-Profilaktualisierung ([schema.org/Person](https://schema.org/Person)) für BNS-Namen.
- Transaktionsabfragen mit Filtern (Typ, Blockbereich, nicht verankert) und nach Vertrag.
- Mempool: Liste ausstehender Transaktionen, Mempool-Statistiken und abgebrochene Transaktionen.
- Block-Explorer: aktuelle Blöcke, Block nach Höhe oder Hash, stapelt Blöcke für einen bestimmten Bitcoin-Block.
- Vertragsereignisse: Ereignisse für einen Vertrag oder Vermögensereignisse für eine Adresse.
- Token-Metadaten: SIP-10- und SIP-9-Metadaten und -Inhaber.
- Netzwerkinformationen und Zustand/Status.

**Swaps, DeFi und Bridge:**

- Unterstützte Paare und Protokolle ([ALEX](https://alexlab.co/), [Bitflow](https://www.bitflow.finance), [Velar](https://www.velar.co)).
- Swap-Angebot (geschätzte Leistung, Zinssatz, Gebühren) für alle drei; Tausch über ALEX DEX ausführen. Bitflow und Velar unterstützen Angebote und Paarerkennung; Sie könnten die Ausführung über Protokoll-SDKs hinzufügen (z. B. gibt Velar SDK Vertragsaufrufparameter zurück).
- Tauschen Sie den Verlauf der On-Chain-Aktivität aus.
- sBTC-Guthaben und Bridge-Einzahlungs-/Auszahlungsinformationen.
- Stapeln: aktueller PoX-Status, Zyklusinformationen (verbleibende Blöcke, abgeschlossener Prozentsatz, geschätzte verbleibende Zeit, Teilnahmerate), Solo-Stacking initiieren, Delegation widerrufen.

**BNS- und Marktdaten:**

- [BNS](https://docs.stacks.co/docs/stacks-blockchain/bns) Suche (Name zu Adresse), Namen im Besitz der Adresse, BNS-Namen registrieren.
- Multi-Asset-Preise (z. B. [CoinGecko](https://www.coingecko.com)); Preisverlauf für Diagramme.
- Portfolioübersicht (BTC + STX in USD); alle Vermögenswerte und Sammlerstücke (Inschriften, Stacks NFTs).

**Ledger (Stacks-App):**

- Holen Sie sich Stacks-Adressen von Ledger.
- Unterzeichnen Sie die Stacks-Transaktion mit der Ledger Stacks-App.

## Sicherheit und Design

⚠️ Dieser MCP-Server ist experimentell und für bedeutende Gelder nicht sicher. Verwenden Sie es nur mit Geldbörsen, die Sie gerne verlieren würden. Niemand hat den Code kampferprobt oder geprüft. Ich betrachte es als Forschungsartefakt zur Erforschung agentennativer Wallet-Oberflächen.

Zerstörerische Operationen sind standardmäßig „dry_run: true“. Für jeden Sendepfad gibt es Vorschau- und Schätzungstools. Schlüssel bleiben außerhalb der Versionskontrolle und außerhalb der Tool-Antworten. Das Ausführungsskript lädt „.env“ aus dem Repo-Root.

**Wallet-Schlüsselvariablen (geheim halten, niemals festlegen):**

- **`BTC_PRIVATE_KEY`** – WIF-codierter privater Bitcoin-Schlüssel; Wenn festgelegt, hat es Vorrang vor der Mnemonik.
- **`BTC_MNEMONIC`** — BIP-39-Seed-Phrase; Der Server verwendet es, um Bitcoin- und Stacks-Schlüssel abzuleiten (gleiche Mnemonik, Pfad „m/44“/5757“/0“/0/0“ für Stacks).
- **`BTC_MNEMONIC_PASSPHRASE`** – Optionale BIP-39-Passphrase zur Verwendung mit `BTC_MNEMONIC`.

**Sicherheit und Grenzen (env oder .env):**

- **`BTC_NETWORK`** — `mainnet` oder `testnet` (Standard `testnet`).
- **`BTC_MAINNET_ENABLED`** – Legen Sie dies fest, um Mainnet-Sendungen zuzulassen (Sicherheitsflag).
- **`BTC_DRY_RUN`** – Wenn festgelegt (Standard), werden destruktive Operationen (Senden, Signieren und Senden, Bereitstellen) nicht gesendet; Setzen Sie es auf „false“, um echte Transaktionen zu ermöglichen.
- **`BTC_MAX_SEND_BTC`** – Optionale Obergrenze für den Sendebetrag in BTC; Darüber hinausgehende Anfragen lehnt der Server ab.
- **`BTC_MAX_FEE_SATS`** – Optionale Obergrenze der Gebühr in Satoshis pro Transaktion.
- **`STX_ACCOUNT_INDEX`** – Stacks-Ableitungskontoindex (Standard „0“).
– Die Konfiguration steuert ansonsten die Gebührenstufe (Festpreis oder mempool.space-Stufe: Stunde, halbe Stunde, schnellste).

## Wie es zu meinem Agentenstapel passt

Ich betreibe Agenten auf einer dreischichtigen Architektur. Die Schichten sind sauber getrennt, sodass Erinnerung, Argumentation und Handlung an der richtigen Stelle bleiben.

**Wahrheitsschicht:** Dies ist das Speichersubstrat. Es enthält typisierte, strukturierte Daten: Bestände, Bewegungen, Transaktionen, Kontakte, Aufgaben und mehr. In meinem Setup ist der kanonische Speicher [Neotoma](/posts/truth-layer-agent-memory). Es verwendet Event Sourcing und Reducer mit vollständiger Herkunft und Entitätsauflösung. Agenten lesen daraus vor. Sie schreiben die Wahrheit nie direkt. Alle Aktualisierungen erfolgen über Domänenereignisse, die von der Ausführungsschicht erzeugt werden.

**Strategieebene:** Hier leben Ziele, Einschränkungen und Taktiken. Hier finden Sie Strategiedokumente, taktische Spielbücher und Betriebshandbücher. Agenten nutzen diese Ebene, um zu argumentieren: Sie lesen die Weltlage, bewerten Prioritäten und Risiken und treffen Entscheidungen und Befehle. Strategie ist reine Erkenntnis. Keine Nebenwirkungen. Staat rein, Entscheidungen raus.

**Ausführungsschicht:** Hier finden externe Aktionen statt. Es nimmt Befehle von der Strategieebene entgegen und führt Nebeneffekte über Adapter aus: E-Mail, Kalender, DNS und in diesem Fall das Bitcoin- und Stacks-Wallet-MCP. Der Wallet-Server ist ein Ausführungsadapter unter vielen. Es verändert niemals die Wahrheitsschicht. Es erledigt die Aufgabe (senden, signieren, tauschen) und der Rest des Stapels zeichnet über Domänenereignisse auf, was passiert ist. Befehle rein, Ereignisse raus.

Ich definiere und pflege die Strategie. Agenten lesen aus der Wahrheitsschicht und rufen MCP-Tools zur Ausführung auf. Ich verwende keine Point-and-Click-Krypto-Benutzeroberflächen für Routinevorgänge. Ich greife nur ein, um Aktionen zu genehmigen, die meine voreingestellten Grenzen überschreiten.

Kurzfristig sind meine Anwendungsfälle einmalig: Bezahlung von Dienstleistungen, Neuausrichtung von Portfolios durch manuelle Eingabeaufforderungen. Längerfristig möchte ich, dass diese Abläufe automatisiert werden. Agenten würden die Richtlinien überwachen, begründen und ausführen. Ich würde mir die Erklärungen ansehen und bei Bedarf zustimmen.

## Wie ich an den Bau herangehe

Ich füttere den Server zunächst in meinen eigenen Arbeitsabläufen mit Dogfood. Ich teste jede Oberfläche (Sends, PSBTs, Ordinals, Stacks-Transfers, Swaps) nach und nach mit kleinen Mengen und Probeläufen.

Ich habe es in denselben Stapel eingebunden, in dem ich bereits [Wahrheits- und Strategieebenen] verwende (/posts/agentic-search-and-the-truth-layer#where-ive-hit-limits). Agenten können Wallet-Aktionen mit Kalender, E-Mail und Daten kombinieren. Externe Benutzer sind noch nicht im Geltungsbereich.

Mein Ziel ist es, die Form einer Agenten-Wallet-Oberfläche zu validieren und meine eigenen Bitcoin- und Stacks-Operationen agentengesteuert statt manuell zu gestalten.

Um es auszuführen: Klonen Sie [mcp-server-bitcoin](https://github.com/markmhendrickson/mcp-server-bitcoin) (oder fügen Sie es als Submodul unter „mcp/btc_wallet/“ hinzu), fügen Sie den Server zu Ihrer MCP-Konfiguration hinzu (verwenden Sie den Skriptpfad „run_btc_wallet_mcp.sh“) und verwenden Sie ein Test-Wallet mit aktiviertem Trockenlauf.