Este fin de semana armé un servidor MCP para una billetera Bitcoin: herramientas a las que los agentes de IA pueden llamar a través del Protocolo de Contexto Modelo. El [repo](https://github.com/markmhendrickson/mcp-server-bitcoin) expone 93 herramientas en la Capa 1 y la Capa 2. Un mnemotécnico controla ambas. Anteriormente fui gerente general de [Leather](https://leather.io), una billetera criptográfica que también admite Bitcoin y Stacks. En Leather vi que las billeteras de autocustodia orientadas a humanos llegaban principalmente a personas dispuestas a absorber la atención y la complejidad (por ejemplo, degens y desarrolladores). Eso significaba higiene de claves, conocimiento de tarifas, flujos de confirmación y todo lo demás. La carga cognitiva mantuvo estrecho el mercado real al que se podía dirigir. Las carteras agentes cambian eso. Cuando la interfaz principal son agentes que razonan y ejecutan dentro de la política, el usuario aprueba sólo lo que importa. La fricción disminuye y crece el conjunto de personas que prácticamente pueden tener sus propias llaves. Las mismas dos cadenas. Superficie diferente. ## Lo que expone el servidor (L1 y L2 en una superficie) El servidor es un proceso MCP único. Los clientes envían nombres de herramientas y argumentos JSON a través de stdio y obtienen resultados estructurados. Las acciones destructivas (envíos, firma y transmisión, implementación) admiten `dry_run` y no transmiten de forma predeterminada. El servidor nunca devuelve claves ni mnemotécnicos. ### Capa 1 (Bitcoin) **Bitcoin central:** - Derivación de direcciones para P2PKH, P2SH-P2WPKH, P2WPKH y P2TR con claves y rutas públicas. - Cuentas con saldos por tipo de dirección ([mempool.space](https://mempool.space) para datos UTXO); saldo de la billetera y precios de BTC (USD, EUR). - Envíos de destinatario único y múltiple (cantidad en BTC o EUR); vista previa de la transferencia con estimación de tarifa antes de enviar. - Barrido (envío máximo) y consolidación UTXO. - Firma, decodificación y firma por lotes de PSBT; firmar y verificar mensajes (heredado ECDSA y BIP-322). - Niveles de tarifas de mempool.space y estimación de tarifas por recuento de entrada/salida y tipo de dirección. - Listado de UTXO con filtros (tipo de dirección, valor mínimo, solo confirmado) y detalles por UTXO. **Ordenales e inscripciones:** - Listar inscripciones con paginación; detalles de inscripción (génesis, tipo de contenido, ordinal sat, rareza, ubicación). - Enviar inscripciones (UTXO completo o dividido para que solo el rango sat de la inscripción llegue al destinatario). - Extraer ordinales de UTXO mixtos; recuperar BTC de la dirección ordinal (barrer UTXO sin inscripción); recuperar los ordinales que llegaron a la dirección de pago a la dirección principal. - Cree inscripciones individuales o por lotes con estimaciones de tarifas de confirmación/revelación. **Gestión de transacciones y billetera:** - Historial de transacciones para BTC y Stacks; estado para un solo tx. - Acelerar BTC pendientes a través de RBF; cancelar BTC pendiente (envío a uno mismo de RBF). - Configuración de red y puntos finales API; cambiar la red principal/testnet; agregar red personalizada. - Enumere todos los nombres y descripciones de herramientas compatibles. **Libro mayor (aplicación Bitcoin):** - Obtenga direcciones BTC desde un dispositivo [Ledger](https://www.ledger.com) conectado. - Firme PSBT con la aplicación Ledger Bitcoin. ### Capa 2 (pilas) El mismo mnemotécnico deriva las claves de Stacks (ruta `m/44'/5757'/0'/0/0`). [Hiro](https://hiro.so) API de pilas para transmisión y datos en cadena. **Pilas:** - Direcciones y claves públicas; cuentas con saldo STX, montos bloqueados, nonces. - Saldo que incluye tokens fungibles y no fungibles. - Transferencia STX (micro-STX) con nota opcional; vista previa de transferencia con tarifa y verificación de saldo. - Transferencias SIP-10 fungibles y SIP-9 NFT mediante llamadas de contrato. - Claridad: llamar a función pública, implementar contrato, llamada de solo lectura. - Firmar Stacks tx serializados (SIP-30), firmar mensajes, firmar datos estructurados SIP-018; estimación de honorarios y nonce. - Actualización de perfil en cadena ([schema.org/Person](https://schema.org/Person)) para nombres BNS. - Consultas de transacciones con filtros (tipo, rango de bloques, no anclados) y por contrato. - Mempool: lista de transacciones pendientes, estadísticas de mempool, transacciones descartadas. - Explorador de bloques: bloques recientes, bloque por altura o hash, bloques de pila para un bloque de Bitcoin determinado. - Eventos de contrato: eventos para un contrato, o eventos de activo para una dirección. - Metadatos de tokens: metadatos y titulares SIP-10 y SIP-9. - Información de red y salud/estado. **Swaps, DeFi y puente:** - Pares y protocolos admitidos ([ALEX](https://alexlab.co/), [Bitflow](https://www.bitflow.finance), [Velar](https://www.velar.co)). - Cotización swap (producción estimada, tasa, tarifas) para los tres; ejecutar el intercambio a través de ALEX DEX. Bitflow y Velar admiten cotizaciones y descubrimiento de pares; puede agregar ejecución a través de SDK de protocolo (por ejemplo, Velar SDK devuelve parámetros de llamada de contrato). - Intercambiar historial de actividad en cadena. - Saldo sBTC e información de depósito/retiro puente. - Apilamiento: estado actual de PoX, información del ciclo (bloques restantes, porcentaje completado, tiempo restante estimado, tasa de participación), iniciar apilamiento en solitario, revocar delegación. **BNS y datos de mercado:** - Búsqueda [BNS](https://docs.stacks.co/docs/stacks-blockchain/bns) (nombre a dirección), nombres propiedad de la dirección, registro del nombre BNS. - Precios de múltiples activos (por ejemplo, [CoinGecko](https://www.coingecko.com)); historial de precios para gráficos. - Resumen de cartera (BTC + STX en USD); todos los activos y coleccionables (inscripciones, Stacks NFT). **Libro mayor (aplicación Stacks):** - Obtener direcciones de Stacks de Ledger. - Firmar transacción Stacks con la aplicación Ledger Stacks. ## Seguridad y diseño ⚠️ Este servidor MCP es experimental y no es seguro para fondos significativos. Úselo sólo con carteras que esté dispuesto a perder. Nadie ha probado en batalla ni auditado el código. Lo trato como un artefacto de investigación para explorar las superficies de las billeteras nativas de los agentes. Las operaciones destructivas tienen por defecto `dry_run: true`. Existen herramientas de vista previa y estimación para cada ruta de envío. Las claves permanecen fuera del control de versiones y de las respuestas de las herramientas. El script de ejecución carga `.env` desde la raíz del repositorio. **Variables clave de la billetera (mantener en secreto, nunca confirmar):** - **`BTC_PRIVATE_KEY`** — Clave privada de Bitcoin codificada con WIF; si se establece, tiene prioridad sobre la mnemónica. - **`BTC_MNEMONIC`** — frase inicial BIP-39; el servidor lo usa para derivar claves de Bitcoin y Stacks (mismo mnemónico, ruta `m/44'/5757'/0'/0/0` para Stacks). - **`BTC_MNEMONIC_PASSPHRASE`**: frase de contraseña BIP-39 opcional para usar con `BTC_MNEMONIC`. **Seguridad y límites (env o .env):** - **`BTC_NETWORK`** — `mainnet` o `testnet` (`testnet` predeterminado). - **`BTC_MAINNET_ENABLED`**: configúrelo para permitir envíos a la red principal (indicador de seguridad). - **`BTC_DRY_RUN`** — Cuando está configurado (predeterminado), las operaciones destructivas (envío, firma y transmisión, implementación) no se transmiten; configúrelo en "falso" para permitir transacciones reales. - **`BTC_MAX_SEND_BTC`** — Límite opcional en el monto de envío en BTC; el servidor rechaza las solicitudes superiores a esta. - **`BTC_MAX_FEE_SATS`** — Límite opcional de tarifa en satoshis por transacción. - **`STX_ACCOUNT_INDEX`** — Índice de cuenta de derivación de pilas (predeterminado `0`). - De lo contrario, la configuración controla el nivel de tarifa (tasa fija o nivel mempool.space: hora, media hora, más rápido). ## Cómo encaja en mi pila de agentes Ejecuto agentes en una arquitectura de tres capas. Las capas están claramente separadas para que la memoria, el razonamiento y la acción permanezcan en el lugar correcto. **Capa de verdad:** Este es el sustrato de la memoria. Contiene datos estructurados y tipificados: existencias, flujos, transacciones, contactos, tareas y el resto. En mi configuración, la tienda canónica es [Neotoma](/posts/truth-layer-agent-memory). Utiliza fuentes de eventos y reductores, con procedencia completa y resolución de entidades. Los agentes lo leen. Nunca escriben la verdad directamente. Todas las actualizaciones fluyen a través de eventos de dominio producidos por la capa de ejecución. **Capa de estrategia:** Aquí es donde viven los objetivos, las limitaciones y las tácticas. Aquí se encuentran documentos de estrategia, manuales de jugadas tácticas y manuales de operaciones. Los agentes utilizan esta capa para razonar: leen el estado mundial, evalúan prioridades y riesgos y producen decisiones y comandos. La estrategia es pura cognición. Sin efectos secundarios. Estado dentro, decisiones fuera. **Capa de ejecución:** Aquí es donde ocurren las acciones externas. Toma comandos de la capa de estrategia y realiza efectos secundarios a través de adaptadores: correo electrónico, calendario, DNS y, en este caso, la billetera MCP de Bitcoin y Stacks. El servidor de billetera es un adaptador de ejecución entre muchos. Nunca muta la capa de verdad. Hace lo que sucede (enviar, firmar, intercambiar) y el resto de la pila registra lo que sucedió a través de eventos de dominio. Comandos adentro, eventos afuera. Defino y mantengo la estrategia. Los agentes leen desde la capa de verdad y llaman a las herramientas MCP para ejecutarlas. No uso interfaces de usuario criptográficas de apuntar y hacer clic para operaciones de rutina. Sólo intervengo para aprobar acciones que exceden mis límites preestablecidos. A corto plazo, mis casos de uso son únicos: pagar servicios, reequilibrar carteras mediante indicaciones manuales. A largo plazo quiero que esos flujos se automaticen. Los agentes monitorearían, razonarían y ejecutarían dentro de la política. Vería explicaciones y las aprobaría cuando fuera necesario. ## Cómo me acerco a la construcción Primero estoy probando el servidor en mis propios flujos de trabajo. Estoy probando cada superficie (envíos, PSBT, ordinales, transferencias de pilas, intercambios) gradualmente con pequeñas cantidades y ensayos. Lo conecté a la misma pila donde ya uso [capas de verdad y estrategia](/posts/agentic-search-and-the-truth-layer#where-ive-hit-limits). Los agentes pueden combinar acciones de billetera con calendario, correo electrónico y datos. Los usuarios externos aún no están dentro del alcance. Mi objetivo es validar la forma de una superficie de billetera agente y hacer mis propias operaciones de Bitcoin y Stacks impulsadas por agentes en lugar de manuales. Para ejecutarlo: clone [mcp-server-bitcoin](https://github.com/markmhendrickson/mcp-server-bitcoin) (o agréguelo como submódulo en `mcp/btc_wallet/`), agregue el servidor a su configuración de MCP (use la ruta del script `run_btc_wallet_mcp.sh`) y use una billetera de prueba con ejecución en seco activada.