BridgeKitty 🐱

Cross-Chain-Bridge-Aggregator-MCP-Server für KI-Agenten. Ein Server, 5 Bridge-Backends, beste Routen über EVM-, Solana- und Cosmos-Chains.

BridgeKitty gibt KI-Agenten (Claude, Cursor, GPT oder jede MCP-kompatible KI) die Fähigkeit, Cross-Chain-Bridge-Transfers zu finden und auszuführen – mit automatischer Routenoptimierung, Gebührenvergleich, Saldoüberprüfungen und Sicherheitswarnungen.

Neuestes npm-Release: @persistenceone/bridgekitty@0.3.9

Was ist neu in v0.3.9

• XPRT-Tools extrahiert — Staking-, Rewards- und Farming-Tools wurden in das eigenständige xprt-farming-toolkit-Paket verschoben

• Persistence Interop-Backend entfernt — BridgeKitty ist jetzt ein fokussierter Bridge-Aggregator über 5 Backends (deBridge, Relay, LI.FI, Across, Squid)

• Schlankere Oberfläche — weniger Tools, klarerer Anwendungsbereich für Agenten

• sign_and_send-Parameter — Agenten können jetzt Transaktionen direkt mit lokal gespeicherten Wallet-Keys signieren und übertragen

• Vollständige EVM-Signierungsunterstützung — funktioniert mit allen EVM-Backends (Across, Relay, LI.FI, Squid, deBridge) + Persistence Interop (EIP-712)

• Simulations-Fix — ERC20-Bridges funktionieren jetzt bei neuen Wallets (zuvor durch vorzeitige Simulation blockiert)

• Solana-Signierung — kommt im nächsten Release

• Solana-Unterstützung — bidirektionales Bridging EVM ↔ Solana (native SOL-Zustellung, nicht gewrappt)

• Cosmos-Unterstützung — EVM → Persistence/Cosmos Hub via Squid (Axelar)

• Transparenz der Protokollgebühren — deBridge fixFee, Betriebskosten und Gesamtkosten in jedem Angebot sichtbar

• Saldo-Warnungen — warnt, wenn das Wallet den Bridge-Betrag + Protokollgebühren + Gas nicht decken kann

• XPRT-Staking — Staking/Unstaking/Claiming von Rewards direkt vom MCP-Server aus

• Farming-Multiplikator — verfolgt dein Staking-Tier (1x → 3x → 5x) über die Rewards-API

• Automatische Aktualisierung von Angeboten — abgelaufene Angebote werden bei der Ausführung automatisch neu abgerufen (60s Ablaufzeit)

• ERC-20-Genehmigungen — werden immer für Token-Bridges generiert (Relay + deBridge)

• Bridge-Status-Tracking — On-Chain-Fallback, wenn der Provider-API noch nicht indexiert hat

Related MCP server: deBridge MCP Server

Unterstützte Bridges

Bridge-Richtungen

Schnellstart

npx (keine Installation)

npx @persistenceone/bridgekitty

Claude Code

Zur MCP-Konfiguration hinzufügen (~/.claude/claude_code_config.json):

{
  "mcpServers": {
    "bridgekitty": {
      "command": "npx",
      "args": ["@persistenceone/bridgekitty"]
    }
  }
}

Cursor IDE

Zu den MCP-Einstellungen von Cursor hinzufügen (Settings > MCP Servers):

{
  "bridgekitty": {
    "command": "npx",
    "args": ["@persistenceone/bridgekitty"]
  }
}

Claude Desktop

Zu claude_desktop_config.json hinzufügen:

{
  "mcpServers": {
    "bridgekitty": {
      "command": "npx",
      "args": ["@persistenceone/bridgekitty"]
    }
  }
}

Wallet-Einrichtung

BridgeKitty kann Wallets für autonomes Bridging verwalten. Führe wallet_setup aus, um Wallets für EVM, Cosmos und Solana zu erstellen – oder gib deine eigenen Adressen in den Angeboten an.

Die Wallet-Konfiguration wird in ~/.bridgekitty/.env gespeichert (oder in dem Verzeichnis, aus dem du das Programm ausführst). Keys verlassen niemals den lokalen Rechner.

Transaktionssignierung

Standardmäßig gibt bridge_execute unsignierte Transaktionen zurück, die der Agent oder Benutzer extern signieren muss.

Setze sign_and_send: true, um autonomes Signieren zu aktivieren — BridgeKitty verwendet die in ~/.bridgekitty/.env gespeicherten Wallet-Keys, um den gesamten Ablauf zu handhaben:

1. Genehmigung — sendet die ERC-20-Genehmigungstransaktion (falls erforderlich)

2. Neuaufbau — ruft die Bridge-Transaktion mit aktualisierter Nonce erneut ab (falls eine Genehmigung gesendet wurde)

3. Simulation — führt einen eth_estimateGas-Pre-Flight-Check durch

4. Signieren — signiert die Transaktion mit dem lokalen Private Key

5. Übertragung — sendet sie an die Chain und gibt den Tx-Hash + Explorer-Link zurück

Optionale API-Keys

MCP-Tools

Core-Bridge-Tools

Multi-Hop & Discovery

Wallet-Tools

XPRT-Staking & Farming wurde in das eigenständige xprt-farming-toolkit-Paket verschoben.

Beispiel: Bridge USDC von Base nach Arbitrum

Standard (unsignierte Transaktionen)

Agent: "Bridge 100 USDC from Base to Arbitrum"

→ bridge_get_quote: Gets quotes from deBridge, Relay, LI.FI, Across
→ Shows: best rate, fees, estimated time, balance check
→ bridge_execute: Builds approval tx + bridge tx
→ Agent signs and sends both transactions
→ bridge_status: Tracks until destination confirmed

Mit sign_and_send (autonomes Signieren)

Agent: "Bridge 100 USDC from Base to Arbitrum"

→ bridge_get_quote: Gets quotes from all backends
→ bridge_execute with sign_and_send: true
  → Auto-signs approval tx + bridge tx using local wallet keys
  → Returns tx hash + explorer link
→ bridge_status: Tracks until destination confirmed

Architektur

Agent → MCP Tools → Routing Engine → [deBridge, Relay, LI.FI, Across, Squid]
                         ↓
                   Quote Cache (60s) + Circuit Breaker
                         ↓
                   Best Quote → buildTransaction
                         ↓
              ┌──────────┴──────────┐
              ↓                     ↓
        Unsigned TX          Signed + Broadcast
         (default)            (sign_and_send)

• Routing-Engine: Parallele Angebote von allen Backends, sortiert nach Ausgabebetrag

• Circuit Breaker: Überspringt automatisch fehlerhafte Backends, schrittweise Wiederherstellung

• Token-Registry: 45+ verifizierte Token mit kanonischen Adressen pro Chain

• Gas-Schätzer: Chain-bewusste Gas-Kostenschätzung mit Multi-RPC-Failover

• Saldo-Prüfer: Validiert Token- + natives Guthaben für Gebühren vor der Ausführung

• Gebührentransparenz: Protokollgebühren (deBridge fixFee, Betriebskosten) werden in jedem Angebot angezeigt

Sicherheit

• Nur exakte Genehmigungsbeträge (niemals unbegrenzt)

• Transaktionssimulation vor der Ausführung

• Verifizierte Token-Registry verhindert Adress-Spoofing

• Keine Private Keys im MCP-Protokoll — Agenten signieren Transaktionen extern

• sign_and_send verwendet nur lokal gespeicherte Keys (werden niemals über das Netzwerk übertragen)

• Circuit Breaker verhindert kaskadierende Fehler

• Fehlermeldungen bereinigt (kein Leak von Keys/Pfaden)

• .env-Datei-Berechtigungsprüfungen + Überschreibungsschutz

Bekannte Einschränkungen

• Solana → EVM gibt eine serialisierte Transaktion für die externe Signierung zurück (keine automatische Ausführung)

• Relay-Status-Tracking zeigt möglicherweise "unbekannt" für abgeschlossene Cross-Chain-Bridges an

• Solana SPL-Token werden noch nicht in wallet_balance angezeigt (nur natives SOL)

• Cosmos → EVM Bridging noch nicht unterstützt (nur EVM → Cosmos)

Lizenz

MIT