--- title: "Cómo desarrollar en cadenas UTXO: Bitcoin, Litecoin, Dogecoin y Bitcoin Cash" description: "Cadenas UTXO para desarrolladores: en qué se diferencian Bitcoin, Litecoin, Dogecoin y Bitcoin Cash de EVM, qué infraestructura necesitas y cómo la ofrece Alchemy." --- # Cómo desarrollar en cadenas UTXO: Bitcoin, Litecoin, Dogecoin y Bitcoin Cash Bitcoin no tiene balances de cuenta. Nunca los ha tenido. Tampoco los tienen Litecoin, Dogecoin ni Bitcoin Cash. Estas cuatro cadenas comparten un diseño de 2009 llamado el [modelo UTXO](https://www.alchemy.com/docs/bitcoin/utxo), que reemplaza la máquina de estados de "una fila por dirección" que todo desarrollador de Ethereum y Solana da por sentada. El modelo funciona a nivel de protocolo. Se rompe en la capa de aplicación, donde cada consulta básica que tu app necesita hacer, o no existe, o tiene que ser reconstruida por un indexador externo. Por eso los equipos que construyen en cadenas UTXO han pasado años ensamblando infraestructura: un proveedor para RPC, otro para lecturas indexadas, un tercero para webhooks, código custom para llenar los vacíos. Nuestro paquete UTXO colapsa todo esto en una sola plataforma en las cuatro cadenas, con el mismo dashboard, las mismas API keys y el mismo medidor de uso que usas para [EVM](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm) y [Solana](https://www.alchemy.com/solana). ## ¿Qué tienen de distinto las cadenas UTXO? UTXO significa "unspent transaction output" (salida de transacción no gastada). Cada transacción de Bitcoin consume una o más salidas como entradas y crea nuevas salidas. El "balance" de una wallet no está almacenado en ningún lugar de la cadena. Se calcula sumando cada salida que la wallet controla y que aún no ha sido gastada. La [guía para desarrolladores de Bitcoin](https://developer.bitcoin.org/devguide/transactions.html) lo dice explícitamente: "cuando tu wallet de Bitcoin te dice que tienes un balance de 10,000 satoshis, en realidad significa que tienes 10,000 satoshis esperando en una o más UTXOs." Un ejemplo concreto. Alice controla tres UTXOs: 0.4 BTC, 0.3 BTC y 0.2 BTC. Envía 0.5 BTC a Bob. La transacción consume por completo sus salidas de 0.4 y 0.3 BTC, crea una salida de 0.5 BTC para Bob, devuelve ~0.1999 BTC como cambio a una nueva dirección que Alice controla, y deja ~0.0001 BTC como fee del minero. La UTXO de 0.2 BTC queda intacta. Las UTXOs son atómicas. No puedes gastar una parcialmente. El contraste con las cadenas basadas en cuentas es marcado: [Litecoin](https://www.alchemy.com/rpc/litecoin), [Dogecoin](https://www.alchemy.com/rpc/dogecoin) y [Bitcoin Cash](https://www.alchemy.com/rpc/bitcoin-cash) heredan todos este modelo. Bifurcaron el código de Bitcoin, ajustaron los tiempos de bloque y algunos parámetros, y lo lanzaron. El mismo modelo mental y el mismo tipo de infraestructura sirven a las cuatro cadenas. ## ¿Por qué le importa esto a los devs? Las diferencias no son filosóficas. Aparecen en lugares concretos donde la mayoría de los equipos subestima el trabajo requerido. ### No puedes pedirle a un nodo el balance de una dirección Bitcoin Core almacena bloques y transacciones. No mantiene un índice de dirección a transacción. Los core developers se han [resistido explícitamente](https://bitcoincore.reviews/14053) a agregar uno porque, como dijo un maintainer, "los índices de direcciones son inherentemente inescalables porque crecen linealmente con el tamaño de la blockchain." Su posición es que la indexación de direcciones pertenece a servicios externos. Así que cada app de Bitcoin que necesita mostrar un balance, listar las transacciones de un usuario o vigilar pagos entrantes, se apoya en un indexador: un servicio que observa la cadena y mantiene una base de datos consultable de direcciones, transacciones y UTXOs. La única pregunta es quién lo opera. La mayoría de los equipos usan [un proveedor de nodos de blockchain hospedado](https://www.alchemy.com/overviews/blockchain-node-providers) en lugar de levantar su propia infraestructura. ### Las wallets no tienen una dirección, tienen miles Reutilizar una dirección vincula cada entrada y salida bajo una sola identidad. Por eso la convención es una dirección por recepción, derivada de una sola semilla mediante claves jerárquicas determinísticas (HD) definidas en [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). Un exchange que mantiene un solo xpub corporativo (una clave pública extendida que puede derivar un árbol de direcciones de recepción a partir de una sola raíz, sin exponer las claves privadas que las gastan) puede mostrarle a cada cliente una dirección de depósito recién derivada. Una wallet autocustodiada puede recalcular cada UTXO que controla a partir de una semilla de 12 palabras. La trampa: un indexador debe derivar direcciones secuencialmente y vigilarlas todas, con el [límite de gap de 20 direcciones de BIP 44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) determinando cuándo detenerse. Si te saltas 20 direcciones, el indexador cree que ya terminó, lo cual es una causa real de los tickets de "¿a dónde se fueron mis fondos?". ### Los fees se pagan por tamaño, no por valor La unidad es satoshis por byte virtual. Una wallet que consolida 100 UTXOs pequeñas en una sola salida paga un fee proporcional a esas 100 entradas, sin importar el valor transferido. La estimación depende del mempool y varía minuto a minuto. Las transacciones atascadas se aceleran con [replace-by-fee (BIP 125)](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) o [child-pays-for-parent](https://bitcoinops.org/en/topics/cpfp/). Nada de esto es conceptualmente difícil. Todo esto es código de producción real que de otra forma tendrías que escribir tú mismo. ### La finalidad es probabilística Un bloque de Bitcoin puede ser reorganizado fuera de la cadena por uno competidor. Cuando eso pasa, cada transacción en los bloques desplazados vuelve al mempool. Las salidas que estaban "gastadas" vuelven a estar no gastadas. Tu indexador tiene que revertir el estado limpiamente o le entrega a tu app un balance incorrecto. Las apps se protegen con umbrales de confirmación: 1 confirmación para pagos de bajo valor, 6 como el estándar histórico, 30+ para depósitos grandes de exchange. Litecoin y Dogecoin tienen tiempos de bloque más cortos (2.5 minutos para LTC, 1 minuto para DOGE), así que el mismo número de confirmaciones compra menos seguridad en tiempo real. ### Los formatos de dirección siguen cambiando Bitcoin ha lanzado tres actualizaciones de formato de dirección sin retirar las anteriores: P2SH en 2012, SegWit en 2017, y Taproot en 2021. Cuatro familias coexisten hoy en la red: legacy P2PKH (`1...`), SegWit anidado P2SH (`3...`), SegWit nativo P2WPKH (`bc1q...`), y Taproot P2TR (`bc1p...`). Una transacción P2WPKH de 1 entrada y 2 salidas pesa aproximadamente [141 bytes virtuales](https://learnmeabitcoin.com/technical/transaction/size/) frente a ~226 vB de la transacción P2PKH equivalente, así que la elección de formato tiene consecuencias directas en los fees. Las wallets y exploradores de producción deben soportar los cuatro. Todo equipo que construye en Bitcoin gasta buena parte de su primer trimestre en esta lista. La mayor parte no tiene nada que ver con el producto que están construyendo. ## ¿Cómo soporta Alchemy las cadenas UTXO? Soportamos [Bitcoin](https://www.alchemy.com/rpc/bitcoin), [Litecoin](https://www.alchemy.com/rpc/litecoin), [Dogecoin](https://www.alchemy.com/rpc/dogecoin) y [Bitcoin Cash](https://www.alchemy.com/rpc/bitcoin-cash) en la misma plataforma que Ethereum, Solana y el [resto del directorio de cadenas](https://www.alchemy.com/rpc). Las mismas API keys. El mismo dashboard. El mismo modelo de medición. Los mismos webhooks. Cada feature está disponible en cada tier. Lo que se lanza desde el inicio: - **Passthrough de JSON-RPC crudo** a full nodes corriendo con `-txindex=1`, para cada método estándar de Bitcoin Core (`getblock`, `getrawtransaction`, `estimatesmartfee`, `sendrawtransaction`, y el resto). - **APIs REST indexadas** para balances de direcciones, búsqueda de UTXOs, historial de transacciones paginado, detalles de transacciones enriquecidos, y estado de gasto. Las consultas que Bitcoin Core no puede responder de forma nativa, respondidas en milisegundos. - **Seguimiento de xpub y descriptores** en las cuatro cadenas. Los descriptores de salida especifican cómo derivar direcciones a partir de una clave; nosotros manejamos la derivación a través de los árboles BIP 44, 49, 84 y 86 y el límite de gap estándar de 20 direcciones. Las consultas de balance, UTXO e historial se ejecutan contra todo el conjunto de direcciones derivadas, no solo la primera dirección que enviaste. - **Suscripciones WebSocket** para transacciones confirmadas, actividad de direcciones, nuevos bloques y notificaciones de reorg, con umbrales de confirmación configurables por stream. - **Operaciones de transacción** más allá del broadcast crudo: estimación de fees por niveles rápido, medio y lento (consciente del mempool), construcción de transacciones sin firmar, compilación, verificación y broadcast. - **Wrappers de compatibilidad** para métodos estilo Blockbook `bb_*` (el formato de QuickNode) y estilo Blockdaemon `bd_*`, de modo que las integraciones existentes migren solo con cambios de llamada HTTP. En código, eso se ve así. JSON-RPC crudo para todo lo que un nodo soporta: REST para las consultas que Bitcoin Core no puede responder de forma nativa: Conexiones persistentes para actualizaciones en vivo: La referencia completa, incluyendo cada endpoint y la lista de métodos de los wrappers de migración, está en nuestro [quickstart de Bitcoin API](https://www.alchemy.com/docs/reference/bitcoin-api-quickstart) y la [referencia de Bitcoin JSON-RPC](https://www.alchemy.com/docs/bitcoin/bitcoin-api-overview). Para una lectura más profunda sobre cómo el estado UTXO difiere del estado de cuentas, nuestra [documentación de modelo UTXO vs. cuenta](https://www.alchemy.com/docs/utxo-vs-account-models) cubre la mecánica a nivel de protocolo. ## ¿En qué se diferencia esto de lo que ya existe? Si ya estás construyendo en Bitcoin, probablemente estás usando uno de tres proveedores, cada uno con sus propios vacíos: bb_*, bd_*)", tooltip: "", icon: "", }, alchemy: { title: "Yes", tooltip: "", icon: "" }, quicknode: { title: "N/A", tooltip: "", icon: "" }, blockdaemon: { title: "N/A", tooltip: "", icon: "" }, blockcypher: { title: "N/A", tooltip: "", icon: "" }, id: 6, }, { capability: { title: "Unified dashboard with EVM and Solana", tooltip: "", icon: "", }, alchemy: { title: "Yes", tooltip: "", icon: "" }, quicknode: { title: "No", tooltip: "", icon: "" }, blockdaemon: { title: "No", tooltip: "", icon: "" }, blockcypher: { title: "No", tooltip: "", icon: "" }, id: 7, }, ], }} /> Tres cosas cambian para los builders. ### Un solo proveedor, una sola integración, una sola factura Si ya estás en Alchemy para [Ethereum](https://www.alchemy.com/ethereum), [Base](https://www.alchemy.com/base), [Polygon](https://www.alchemy.com/polygon) o [Solana](https://www.alchemy.com/solana), agregar Bitcoin no es un proyecto de adquisición. Es una cadena que simplemente activas. Las mismas API keys, el mismo medidor de uso, el mismo modelo de entrega de webhooks, el mismo dashboard. Las configuraciones multi-proveedor que han sido el estándar en cadenas UTXO durante años se colapsan en una sola integración. ### Las cuatro cadenas, un solo conjunto de features Cada proveedor existente cubre alguna combinación de estas cadenas y features, pero la cobertura es dispareja. QuickNode ofrece lecturas indexadas tipo Blockbook y seguimiento de xpub en BTC, LTC y BCH; Dogecoin Blockbook es un add-on de pago separado. Blockcypher ofrece HD Wallets en BTC, LTC y DOGE a través de `wallets/hd`. La Wallet Transact API de Blockdaemon cubre la construcción de transacciones en las cuatro cadenas. Los equipos terminan haciendo coincidir cada caso de uso con el proveedor que soporta la combinación específica de feature y cadena que necesitan, y luego ensamblando el resto con código custom. Nosotros entregamos seguimiento de xpub, lecturas indexadas, operaciones de transacción y suscripciones WebSocket en Bitcoin, Litecoin, Dogecoin y Bitcoin Cash en un solo paquete, sin add-ons por cadena ni divisiones de features. ### Las migraciones son cambios de llamada HTTP, no rearquitecturas Los wrappers de compatibilidad para métodos estilo Blockbook `bb_*` (el formato de QuickNode) y métodos estilo Blockdaemon `bd_*` significan que tus integraciones existentes conservan la forma de su request. Cambias el host. No reescribes el sitio de la llamada. Para los equipos en la superficie REST heredada de Blockcypher, el formato de request sí cambia (usamos REST GET con una forma distinta), pero el modelo de datos subyacente es el mismo. Lanzamos una [guía de migración UTXO](https://www.alchemy.com/docs/bitcoin/utxo-migration-guide) consolidada desde el inicio, con secciones para Blockcypher, QuickNode Blockbook y Blockdaemon. El beneficio para el dev, en una línea: menos infraestructura que ensamblar, menos proveedores que gestionar, y un camino más rápido de "necesitamos soporte de Bitcoin" a tenerlo en producción. ## Construye en Bitcoin con Alchemy Bitcoin, Litecoin, Dogecoin y Bitcoin Cash ya están disponibles en Alchemy junto con Ethereum, Solana y más de 100 cadenas adicionales. Los desarrolladores PAYG agregan cadenas desde el dashboard desde el primer día. Sin contratos, sin lista de espera, sin compromiso mínimo. Los clientes Enterprise obtienen las cadenas UTXO dentro de su asignación existente de unidades de cómputo. Lee [el anuncio de lanzamiento del soporte de Bitcoin](https://www.alchemy.com/blog/alchemy-now-supports-bitcoin) para el desglose completo de features. Crea un endpoint en el [dashboard de Alchemy](https://dashboard.alchemy.com/) y empieza a hacer consultas, o [contacta a ventas](https://www.alchemy.com/contact-sales) para soporte de integración enterprise y precios personalizados.