Hedera y HBAR: 50.000 millones de monedas el primer día, y ninguna más
Una red que dice no ser una blockchain: qué cambia eso, qué costó y en qué números se comprueba
| La pregunta | La respuesta corta |
|---|---|
| ¿Cuánto cuesta usarla? | Las comisiones están marcadas en dólares y se abonan en HBAR. Transferir la moneda cuesta 0,0001 dólares, así que el gasto de un mes se calcula antes de gastarlo |
| ¿Cuándo queda firme un envío? | En cuanto el algoritmo le pone posición y sello de tiempo. No hay confirmaciones que contar ni nada que se pueda deshacer más tarde |
| ¿Y quién decide ese orden? | Una lista definida de nodos, operados por miembros del consejo. El nombre del operador de cada uno viene escrito en la respuesta de la API |
| ¿Entonces no es una blockchain? | No agrupa transacciones en bloques; usa un algoritmo llamado hashgraph. Eso describe la estructura de datos y no dice nada sobre quién puede participar |
| ¿Se mina? ¿Se emiten monedas nuevas? | Ni una cosa ni la otra. Los 50.000 millones se crearon al arrancar la red y no se ha creado ninguna más |
| ¿Qué saco de delegar el saldo? | Apuntas la cuenta a un nodo sin mover ni bloquear las monedas, con un techo de recompensa bajo que fija la gobernanza |
| Lo que a mí me sigue sin cuadrar | Con la comisión en dólares y el suministro cerrado, no veo por dónde llega el uso de la red hasta quien tiene la moneda. La técnica es otra discusión |
1. Cinco consultas que cualquiera puede hacer a la red pública
2. Los nodos de consenso llevan escrito el nombre de quien los opera
3. Dos nodos hablando: qué contiene cada mensaje y qué queda registrado
4. aBFT sin fórmulas, con la condición que casi nunca se menciona
5. Por qué un exchange pide confirmaciones en bitcoin y aquí no cuenta bloques
6. Lados opuestos del mismo problema: lo que la red hace y lo que no hace
7. 50.000 millones creados de una vez y una parte todavía guardada
8. ¿Cuánto renta apuntar tu saldo a un nodo? Los topes mandan
9. Una comisión que puedes presupuestar antes de gastarla
10. Tres servicios y la distancia entre el techo teórico y la carga real
11. El punto que ninguna consulta resuelve: la demanda de la moneda
12. De la patente al código abierto, y otros puntos que suelen contarse mal
13. Mi lectura del diseño y el punto que no consigo cerrar
14. Dónde encaja HBAR en tu recorrido: exchange, monedero y nodo
15. Diccionario mínimo para leer la documentación de Hedera
La API pública de Hedera devuelve la lista de nodos de consenso, y en cada uno viene escrito quién lo opera y desde qué ciudad. Devuelve también cuántas monedas existen, qué parte de ellas sigue guardada en la tesorería, cuál es el techo de lo que se paga por delegar saldo y a qué ritmo se firman las operaciones. Dos de esos datos están fijados por regla y no se mueven con el día: existen 50.000 millones de HBAR, creados de una sola vez y sin ninguno añadido después, y transferir la moneda cuesta 0,0001 dólares. Los demás cambian, así que los he reunido en una sola tabla con la fecha de consulta. Hedera es la red y HBAR es la moneda con la que se paga su uso; todo esto se lee en los llamados nodos espejo, que responden sin registro y sin permisos.
Eso da una ventaja poco común a la hora de escribir sobre este proyecto, porque casi todo se comprueba en lugar de creerse. Cuántos nodos participan en el consenso y quién los opera, cuántas monedas existen, cuántas siguen guardadas, cuánto se paga por delegar, a qué ritmo se firman las operaciones: cada una de esas preguntas se responde con una consulta de dos segundos. Las cifras que aparecen abajo salen de ahí, no de un folleto comercial, y cualquiera puede repetirlas.
Al hacer esas consultas se ve que algunas frases muy repetidas sobre esta red se sostienen bien y otras no se sostienen en absoluto. Voy a separar unas de otras, y al final digo lo que pienso yo, incluido el punto donde creo que puedo estar equivocándome. Cada una de esas lecturas abre una parte del diseño, y el artículo va en ese orden.

1. Cinco consultas que cualquiera puede hacer a la red pública
Estas son las rutas, por si quieres repetir las consultas tú mismo: network/supply para el suministro, network/nodes para la lista de nodos, network/stake para las condiciones de la recompensa, accounts para el saldo de una cuenta concreta y transactions para el ritmo de operaciones. Ninguna de ellas pide clave ni registro.
Lo que está fijado por regla, en cambio, aparece en el cuerpo del artículo sin fecha al lado, porque no depende del día de la consulta: el total de 50.000 millones de monedas, el periodo de recompensa de 24 horas, el límite de 365 días para cobrar recompensas atrasadas y el hecho de que las comisiones estén marcadas en dólares.
| Qué se mide | Valor leído | Ruta consultada |
|---|---|---|
| Nodos de consenso en la red principal | 25 | network/nodes |
| Monedas ya liberadas sobre el total | 43.831.559.711 de 50.000.000.000 (87,7%) | network/supply |
| Parte que sigue en la tesorería | Alrededor del 12,3% | network/supply |
| Techo de la recompensa por delegar | 5.232 tinybars por HBAR y día, cerca del 1,9% anual | network/stake |
| Nodos que ya alcanzaron su tope de respaldo | 8 de 25 | network/nodes |
| Nodos con la marca de no cobrar recompensa | 12 de 25 | network/nodes |
| Saldo total delegado en nodos | Unos 11.300 millones de HBAR | network/stake |
| Saldo de la cuenta que paga las recompensas | Unos 145 millones de HBAR en la cuenta 0.0.800 | accounts/0.0.800 |
| Ritmo real de operaciones (tres muestras) | Unas 2,5 por segundo | transactions |
Con esta tabla delante, el resto del artículo consiste en explicar de dónde sale cada número y qué implica. El orden que sigo va al revés del habitual: primero el precio del diseño, luego el mecanismo que obliga a pagar ese precio, y al final la única cifra que ninguna consulta devuelve, que es la demanda de la moneda.
2. Los nodos de consenso llevan escrito el nombre de quien los opera
Cuando pides la lista de nodos a la API, no recibes un montón de direcciones anónimas. Cada entrada trae un campo de descripción con el nombre de la organización que opera esa máquina y la ciudad donde está. Se leen cosas como “alojado por LG, Singapur”, “alojado por Swirlds, Iowa”, “alojado por Nomura, Tokio”, “alojado por Google, Helsinki” o “alojado por Zain Group, Kuwait”. No hace falta investigar nada: viene escrito en la respuesta.
Es una decisión deliberada de la red. Todos los nodos que participan en el consenso pertenecen a la lista de miembros del consejo que gobierna la red, y esa lista es pública. Aquí no cabe la idea de una máquina anónima, en un sitio que nadie sabe cuál es, decidiendo el orden de las transacciones. Si quieres saber quién ordena las tuyas, lo puedes saber, con nombre y ubicación.
Qué decide el consejo y qué no decide una sola empresa
Los cambios de reglas, la tabla de comisiones y la gestión de la tesorería los decide ese consejo, formado por más de treinta empresas e instituciones de sectores bastante distintos entre sí: banca, telecomunicaciones, tecnología, industria, universidades. Los dos principios que su propia documentación deja por escrito son que todos los miembros tienen el mismo voto y que hay límite de permanencia. El objetivo declarado es que ninguna compañía concentre las decisiones.
Este reparto está más distribuido que el de una red donde un fundador o una fundación única deciden solos, y el voto igualitario con rotación es una defensa real contra la captura por una sola empresa. Al mismo tiempo, esto es claramente distinto de una red donde cualquiera participa en las decisiones sin pedir permiso a nadie.
Un miembro del consejo no es un caso de uso
Aquí hay una confusión que se repite mucho en artículos y en vídeos. Que una empresa conocida figure entre los miembros del consejo te dice que participa en la gobernanza y que, en muchos casos, opera un nodo. No te dice que esa empresa use la red para su negocio. Son dos afirmaciones distintas y solo la primera se puede comprobar con una consulta. Cuando alguien enseña una lista de logotipos como prueba de adopción, está uniendo dos cosas que ninguna API une. Los nombres concretos de la lista, además, se renuevan por el propio límite de permanencia, así que memorizarlos sirve de poco.
3. Dos nodos hablando: qué contiene cada mensaje y qué queda registrado
Paso uno: un cliente envía una transacción a un nodo. Paso dos: ese nodo elige otro nodo al azar y le manda lo que sabe. Paso tres, y aquí está lo específico de esta red: el mensaje no lleva solo transacciones, lleva también el registro de qué recibió antes ese nodo y de quién lo recibió. Ese añadido es lo que da nombre a la técnica, gossip about gossip, que en español se suele dejar tal cual o traducir como chismorreo sobre el chismorreo. El nombre suena informal, pero describe una operación exacta: cada envío incluye el historial de los envíos anteriores.
Paso cuatro: el nodo que recibe guarda ese paquete como un evento con dos referencias, su propio evento anterior y el evento que acaba de llegar. Paso cinco: los nodos repiten esto continuamente, cada uno con destinatarios elegidos al azar. Al cabo de muy poco, todas las máquinas tienen la misma estructura de datos, que registra quién se enteró de qué y en qué momento respecto a los demás.
Por qué los votos no circulan por la red
Ahora viene la parte que la mayoría de resúmenes se salta. Con esa estructura en la mano, un nodo no necesita preguntar a los otros cómo votan para fijar el orden. Puede calcularlo. Como sabe qué información tenía cada nodo y en qué momento la tenía, deduce qué habría respondido cada uno si le hubiera preguntado. A eso se le llama votación virtual: el voto de los demás es un cálculo que cada nodo hace por su cuenta, sin que ningún voto viaje por la red.
La consecuencia práctica es que el tráfico entre máquinas no crece con las rondas de votación, que es justo lo que encarece los sistemas de consenso clásicos. Los nodos gastan comunicación en contarse lo que reciben y gastan cálculo en deducir el resto.
El resultado de todo el proceso son dos cosas por cada transacción: su posición en el orden y su sello de tiempo de consenso. Ese sello se calcula a partir de las marcas de tiempo con las que los distintos nodos recibieron esa transacción, así que ninguna máquina puede decidir sola que algo ocurrió antes o después de lo que ocurrió. A partir de aquí uso estos tres términos sin volver a explicarlos, porque son los nombres del algoritmo y los vas a encontrar igual en cualquier documentación.
4. aBFT sin fórmulas, con la condición que casi nunca se menciona
La etiqueta técnica de este algoritmo es aBFT, tolerancia asíncrona a fallos bizantinos. Vale la pena desmontar las dos palabras, porque cada una promete una cosa distinta.
Bizantino significa que un participante no solo puede apagarse o quedarse sin conexión. Puede mentir: enviar mensajes contradictorios a distintos vecinos, callar información que sí recibió o firmar dos versiones de lo mismo. Un sistema que solo aguanta caídas es mucho más fácil de construir que uno que aguanta mentiras deliberadas.
Asíncrono significa que la garantía no depende de suposiciones sobre el tiempo. No se asume que un mensaje llegue en menos de tantos segundos, ni se usan temporizadores para decidir que alguien ha fallado. La red puede ir lenta, atascarse o entregar los mensajes en desorden, y el resultado sigue siendo el mismo orden para todos.
Con esas dos piezas, la garantía se enuncia así: si menos de un tercio de los participantes falla o miente, el resto llega al mismo orden y al mismo sello de tiempo. Es una demostración matemática, y la demostración se comprobó además con una herramienta automática.
La condición que casi nunca aparece en los resúmenes
Falta una condición para que esa frase signifique algo. Para afirmar “menos de un tercio”, hace falta un denominador. Un tercio de qué. Y un denominador exige saber cuántos participantes hay, lo que exige saber quiénes son. La demostración necesita, entonces, una lista definida de participantes.
En bitcoin ese denominador no existe. Cualquiera enchufa o apaga una máquina sin avisar a nadie, así que el sistema no cuenta participantes; lo que cuenta es trabajo acumulado, y la seguridad se expresa como coste de rehacerlo. Hedera hace lo contrario: cuenta participantes, y por eso necesita conocerlos. Las dos decisiones son coherentes con lo que cada red quiere garantizar, y ninguna de las dos es un descuido.
5. Por qué un exchange pide confirmaciones en bitcoin y aquí no cuenta bloques
Si alguna vez has depositado bitcoin en un exchange, conoces la pantalla: el saldo aparece como pendiente y al lado pone algo del estilo “2 de 3 confirmaciones”. Esa espera tiene un motivo estructural y merece la pena entenderlo, porque es el mejor punto de comparación con lo que hace Hedera.
En las redes que encadenan bloques, el orden vigente es el de la rama con más trabajo acumulado. Si aparece otra rama con más trabajo, los bloques anteriores dejan de contar y las transacciones que iban dentro vuelven a estar pendientes. Esperar confirmaciones reduce la probabilidad de que eso ocurra, y la reduce muy deprisa, pero nunca la lleva a cero. Por eso cada exchange fija su propio número de confirmaciones, según el riesgo que quiera asumir.
Y no es un riesgo teórico. En Litecoin se reorganizaron trece bloques en un episodio documentado, y en Bitcoin Cash ocurrió con dos bloques. Son casos raros y en Bitcoin la profundidad práctica es minúscula, pero existen y son la razón exacta de que la pantalla te haga esperar.
En Hedera no hay confirmaciones que contar porque no hay bloques que apilar. Cuando el algoritmo fija la posición y el sello de tiempo de una transacción, ese resultado ya no depende de lo que pase después, y esa es la regla del algoritmo. No hay una rama alternativa que pueda ganar más adelante ni un número de esperas que sirva para quedarse más tranquilo.
Para un sistema de liquidación importa más saber en qué instante el orden deja de ser provisional que la rapidez a secas. En cuanto llega ese instante, el paso siguiente del proceso puede arrancar, y no hay que fijar a ojo ningún margen de espera.
| Aspecto | Encadenar bloques (bitcoin y familia) | Calcular sobre el registro de mensajes (hashgraph) |
|---|---|---|
| Quién fija el orden | Quien encuentra el siguiente bloque | El algoritmo, a partir del registro que comparten todos los nodos |
| Qué circula por la red | Transacciones y bloques | Transacciones y el historial de qué recibió cada nodo y de quién |
| Naturaleza de la certeza | Probabilidad que sube al acumularse trabajo | Resultado fijado por regla, sin espera adicional |
| Por qué el exchange pide confirmaciones | Porque una rama posterior puede sustituir a la actual | No procede: si el ingreso tarda, es política interna del exchange |
| Quién puede participar en el consenso | Quien tenga equipo, sin lista ni permiso | Una lista definida y publicada de nodos |
| Coste de comunicación al aumentar el acuerdo | Crece con el número de bloques que esperas | No crece con rondas de votos, porque los votos se calculan |
Un matiz práctico para el día a día: aunque la red fije el orden enseguida, el exchange donde ingresas tiene sus propias reglas internas para acreditar un depósito, y esas reglas son de la empresa. Si el saldo tarda en aparecer, casi nunca es cosa de la red. En esta guía sobre depósitos que no se acreditan están los motivos habituales y qué comprobar antes de escribir a soporte.
6. Lados opuestos del mismo problema: lo que la red hace y lo que no hace
Ya se puede juntar todo. Hay dos maneras de resolver el mismo problema, que es decidir en qué orden ocurrieron las cosas cuando nadie manda. Una renuncia a saber quién participa y a cambio acepta que la certeza sea una probabilidad muy alta. La otra exige saber quién participa y a cambio obtiene una certeza fijada por regla. Ninguna de las dos puede quedarse con las dos cosas a la vez.
De ahí sale la frase que más se malinterpreta de este proyecto. “No es una blockchain” es una afirmación sobre la estructura de datos, y es cierta: no hay bloques encadenados. No es una afirmación sobre apertura, ni sobre resistencia a la censura, ni sobre reparto de poder. De hecho, en esos tres terrenos la participación en el consenso está más cerrada aquí que en una red de minería abierta, no más abierta. Quien use el eslogan para deducir superioridad está deduciendo algo que la frase no contiene.
| Hace | No hace |
|---|---|
| Fija el orden y el sello de tiempo de consenso de cada transacción | No hay minería ni recompensa por resolver cálculos |
| Permite emitir y mover tokens con funciones propias de la red, sin escribir un contrato | No crea monedas nuevas: el suministro se emitió entero al arrancar |
| Pone orden y hora a hechos que ocurren en sistemas de terceros | No oculta cuentas ni importes: todo se consulta en abierto |
| Ofrece un entorno de ejecución compatible con las herramientas de Ethereum | No admite que una máquina cualquiera entre en el consenso |
| Publica quién opera cada nodo de consenso y dónde está | No decide sus reglas por votación abierta a cualquiera |
Las dos columnas se resumen en una idea: aquí el orden y el coste quedan fijados por regla, y la participación en el consenso queda limitada a una lista. Todo lo demás del proyecto se entiende mejor a partir de ahí, incluido el papel que tiene la moneda, que es lo que viene ahora.

7. 50.000 millones creados de una vez y una parte todavía guardada
HBAR es la moneda con la que se paga el uso de la red, y todo su suministro se creó el día en que la red arrancó: 50.000 millones de monedas, todas a la vez. Desde entonces no se ha creado ninguna más y no existe ningún mecanismo que las cree. Esto tiene dos consecuencias.
La primera es cómoda para quien tiene monedas: no hay emisión continua que diluya lo que ya existe, ni calendario de recortes de emisión como el que organiza el ritmo de bitcoin, sencillamente porque no hay nada que recortar. La segunda se menciona menos: tampoco hay un presupuesto de monedas nuevas para pagar la seguridad. En una red de minería, la emisión es lo que paga las máquinas que la sostienen. Aquí ese coste lo asumen las empresas del consejo con su propia infraestructura, lo cual es coherente con el diseño y es también una dependencia distinta.
La parte que todavía no circula
No todas las monedas están en el mercado. Una porción sigue en la tesorería de la red y sale según un plan publicado que aprueba el comité correspondiente del consejo, no según lo que pida el mercado en un momento dado. Esa porción es la tercera cifra de la tabla del principio.
Lo que todavía no ha salido diluye a quien ya tiene monedas: cuando salga, habrá más monedas circulando de las que hay hoy. El calendario de salida y el comité del consejo que lo aprueba están publicados, así que la cantidad pendiente y el ritmo previsto se consultan igual que el resto.
De dónde salió el reparto inicial
El punto de partida también fue distinto. Las primeras monedas se colocaron mediante acuerdos de compra futura con inversores cualificados, no mediante un reparto abierto por trabajo de cómputo. Es una diferencia de origen que conviene conocer, sobre todo si vienes de leer sobre redes que arrancaron sin ninguna venta previa.
El tinybar, la unidad que verás en las respuestas
Una nota práctica antes de seguir. Un HBAR se divide en 100.000.000 de tinybars, y esa es la unidad en la que la red expresa internamente comisiones, recompensas y límites. Cuando consultas la API y ves cifras enormes sin decimales, casi siempre estás mirando tinybars. Lo mismo pasa con el techo de recompensa de la tabla inicial, que la red publica en tinybars por HBAR y por día.
8. ¿Cuánto renta apuntar tu saldo a un nodo? Los topes mandan
El staking en esta red funciona de una forma que sorprende a quien viene de otras. No envías monedas a ningún sitio. En la configuración de tu cuenta indicas el identificador de un nodo, y a partir de ahí el saldo de esa cuenta cuenta como respaldo de ese nodo. Las monedas siguen donde estaban, bajo tu control, y se pueden mover o vender en cualquier momento. La documentación lo dice sin rodeos: delegar no implica ningún periodo de bloqueo y el saldo delegado sigue siendo líquido.
Si esto te suena raro comparado con lo que has leído en la guía general sobre staking, es porque muchas redes exigen inmovilizar el saldo durante un plazo. Aquí el nombre es el mismo, pero el compromiso no lo es.
Los tres topes que limitan la recompensa
El cálculo funciona por periodos de 24 horas. Y sobre ese cálculo hay tres límites que conviene conocer antes de hacerse ilusiones con el rendimiento.
El primero es el techo de la tasa. La red publica un máximo de recompensa por moneda y día, que fija la gobernanza, y ese máximo no llega al 2% anual. La cifra exacta está en la tabla del principio del artículo porque puede cambiar. El segundo es el tope por nodo: cada nodo tiene un máximo de respaldo reconocido y todo lo que sobrepase ese tope no entra en el cálculo de recompensas. El tercero es la marca de no cobrar recompensa, que cada nodo activa por su cuenta y que la API muestra nodo por nodo. Cuántos nodos hay en cada una de esas dos situaciones figura en la tabla del principio, porque cambia.
La suma de esos tres límites explica por qué el rendimiento real que ve una cuenta normal es bajo y bastante estable. El mecanismo existe para que el respaldo de la red esté repartido, y como producto de ingresos rinde poco.
De dónde sale el dinero de las recompensas
Aquí está la parte menos intuitiva y la que más vale la pena retener. Como el suministro es fijo, las recompensas no se pagan creando monedas. Salen del saldo de una cuenta del sistema, la 0.0.800, cuyo balance se puede consultar como el de cualquier otra cuenta. Es decir, el fondo de recompensas es un saldo concreto, y rellenarlo es una decisión de gobernanza igual que cualquier otra. Es una diferencia estructural con las redes que financian su staking con emisión nueva, y explica en parte por qué el techo está donde está.
| Condición | Cómo funciona |
|---|---|
| ¿Se mueven las monedas? | No. Apuntas la cuenta a un nodo y el saldo cuenta como respaldo de ese nodo |
| ¿Hay bloqueo? | No hay plazo de inmovilización; el saldo sigue disponible para gastar o vender |
| Periodo de cálculo | 24 horas |
| Origen del pago | El saldo de la cuenta de sistema 0.0.800, no monedas de nueva creación |
| Techo de la tasa | Lo fija la gobernanza y no llega al 2% anual |
| Tope por nodo | El respaldo que supera el tope de un nodo no entra en el cálculo |
| Nodos que renuncian | Una parte de los nodos tiene marcada la opción de no recibir recompensa |
| Recompensas atrasadas | No caducan, pero solo se pueden cobrar hasta 365 días hacia atrás |
Un aviso que ahorra disgustos: lo que aparece en el menú de rendimientos de un exchange no es necesariamente esto. Ahí compras un producto del propio exchange, con sus propios plazos y su propio riesgo de contraparte, y el hecho de que se llame igual no lo convierte en lo mismo. La diferencia está explicada con detalle en el artículo sobre los productos de rendimiento de los exchanges.
9. Una comisión que puedes presupuestar antes de gastarla
Las comisiones de esta red se fijan en dólares por tipo de operación y se pagan en HBAR. La conversión de una cosa a otra la hace la propia red con un tipo de cambio que mantiene internamente para ese uso. Dicho de otro modo: lo que está escrito en la tabla de comisiones es una cantidad en dólares, y la cantidad de monedas que sale de tu cuenta es la que corresponda a esa cantidad en dólares en ese momento.
| Operación | Coste marcado |
|---|---|
| Transferir HBAR | 0,0001 USD |
| Enviar un mensaje al servicio de consenso | 0,0008 USD |
| Transferir un token | 0,001 USD |
| Crear un tema para el servicio de consenso | 0,01 USD |
| Emitir un token no fungible | 0,02 USD |
| Crear una cuenta | 0,05 USD |
Dos precisiones sobre esa tabla. La primera es que los importes están marcados en dólares y se abonan en moneda, como acabo de explicar. La segunda es que la tabla está guardada en el archivo del sistema 0.0.113, que la gobernanza puede modificar y que cualquiera puede consultar.
La ventaja concreta de que el coste esté marcado en dólares
Para quien mueve importes pequeños y muchas veces, esto resuelve un problema concreto: puedes presupuestar. Si sabes cuántas operaciones vas a hacer al mes, sabes lo que te va a costar en dinero real, y ese número no cambia porque la moneda suba o baje. En una red donde la comisión se paga en la propia moneda y sube cuando hay más envíos que sitio en el bloque, ese cálculo no se puede hacer con antelación. Aquí sale con una multiplicación. Para procesos automatizados que emiten muchas operaciones pequeñas, esa previsibilidad es exactamente lo que se busca.
Qué implica esto para tu cuenta
En la práctica necesitas mantener un pequeño saldo de HBAR en la cuenta para pagar lo que hagas, igual que en cualquier otra red necesitas la moneda nativa. Lo que sí sorprende a quien llega de otros sitios es que crear una cuenta tenga un coste, aunque sea muy pequeño. Aquí las direcciones no son gratuitas ni infinitas: son cuentas con un identificador con formato de tres números y su creación se paga.
10. Tres servicios y la distancia entre el techo teórico y la carga real
La red ofrece tres servicios, y verlos por separado ayuda a entender para qué se construyó.
El servicio de tokens permite emitir y mover activos con funciones propias de la red, sin escribir ni desplegar un contrato. Quien haya lidiado con contratos de tokens sabe que ahí se concentra buena parte de los errores caros, así que quitar el contrato de en medio quita también una clase entera de fallos.
El servicio de consenso es el más característico y el peor explicado. Su función es que los hechos ocurridos en otro sistema, en tu base de datos o en la de un socio, reciban un orden y una hora sobre los que nadie discuta. Los datos se quedan donde estaban. Envías un mensaje corto, normalmente una huella del dato y no el dato, y compras solo la prueba de orden. Es el servicio que explica a qué cliente se dirige la red: quien ya tiene los datos en su propio sistema y solo quiere comprar la prueba del orden.
Los contratos inteligentes completan el conjunto con un entorno compatible con las herramientas del ecosistema de Ethereum, para que quien ya programa ahí no tenga que aprender otro lenguaje.
El techo teórico y la carga real
Ahora la parte incómoda de cualquier artículo sobre esta red. Los materiales comerciales citan un límite de operaciones por segundo muy alto, y ese número se repite tanto que acaba tomándose por una medida de lo que la red hace. Ese número es un máximo teórico.
Para no discutir con folletos, medí. Consulté las últimas cien transacciones con sello de tiempo de consenso, calculé los intervalos entre ellas y repetí la operación tres veces. El resultado está en la tabla del principio y ronda un par de operaciones por segundo, que en un día son unos cientos de miles. Hay fuentes secundarias que dan una cifra diaria algo más alta, y da igual cuál se tome: el orden de magnitud es el mismo y está muy lejos del techo anunciado.
Cualquier red tiene capacidad libre, y tener margen es bueno, no malo. Lo criticable es la costumbre de citar el máximo teórico como si describiera el uso, una costumbre que no es exclusiva de este proyecto. Y mi medición tiene su propia letra pequeña: es una foto de un momento, cambia según la hora y no sirve para deducir tendencias.
11. El punto que ninguna consulta resuelve: la demanda de la moneda
Llegamos al punto donde la API deja de ayudar. Todo lo anterior se comprueba con una consulta. Lo que viene ahora no se comprueba con ninguna, y es justo lo que más le importa a quien tiene monedas.
Vuelve a la comisión marcada en dólares y mírala desde el otro lado. Si el precio de la moneda sube, la misma transferencia consume menos monedas, porque lo que está fijado es el importe en dólares y no la cantidad de HBAR. La red recauda una cantidad previsible en dólares con independencia de lo que haga la cotización. Para la empresa que factura ese uso es una noticia excelente, y ya he dicho que me parece la mejor propiedad práctica del diseño. Para quien tiene la moneda, deja una pregunta abierta: por qué camino se convierte más uso de la red en más demanda de HBAR.
Los caminos que sí existen son estos. Hace falta HBAR para pagar comisiones, así que quien opera necesita mantener saldo. Hace falta HBAR para crear cuentas. Y delegar en un nodo apunta el saldo hacia una máquina, pero no lo retira de la circulación, porque no hay bloqueo: mañana lo puedes vender igual. Las recompensas salen del saldo de la cuenta 0.0.800, con un techo que fija la gobernanza, así que tampoco crecen con el uso.
Junta las tres piezas y la conclusión honesta es que la conexión entre uso y demanda existe, pero es más fina de lo que sugiere el discurso habitual. Yo no la voy a resolver aquí, entre otras cosas porque no hay ninguna consulta que devuelva “demanda”. Lo que sí se puede afirmar es lo contrario de lo que se repite: la frase “si la usan muchas empresas, la moneda sube” no se deduce automáticamente de este diseño. Quien quiera defenderla tiene que explicar el camino, no darlo por hecho, y eso es una exigencia razonable para cualquier red, no solo para esta.

12. De la patente al código abierto, y otros puntos que suelen contarse mal
Durante mucho tiempo la crítica más repetida contra este proyecto fue que el algoritmo estaba protegido por patente, con una sola empresa detrás. Era una crítica legítima, y quien la hacía tenía razón en los hechos. Lo que pasa es que la situación del código cambió y muchos textos siguen contándola como estaba antes.
Lo que hay hoy es esto: el consejo compró la propiedad intelectual del algoritmo, el software se publicó con licencia Apache 2.0 y después el software del núcleo de la red se donó a un proyecto alojado en una fundación externa, con el nombre Hiero. La consecuencia práctica es que la propiedad y el mantenimiento del código dejaron de estar atados a una única compañía. Quien quiera criticar el proyecto, y hay material para hacerlo, tiene que apoyarse en la estructura actual y no en la de antes.
Con eso encima de la mesa, aquí van las confusiones que más me he encontrado, corregidas una por una.
| Se oye a menudo | Lo que muestra la red |
|---|---|
| “Se puede minar” | No hay minería de ningún tipo. Todas las monedas existían el primer día y no se ha creado ninguna después |
| “Cada cierto tiempo se recorta la emisión a la mitad” | No hay emisión que recortar, así que ese calendario no existe aquí |
| “Como no es una blockchain, está más descentralizada” | Lo que cambia es la estructura de datos. La participación en el consenso está más cerrada, no más abierta |
| “Hay grandes empresas en el consejo, luego la usan” | Lo comprobable es que participan en la gobernanza y operan nodos. El uso de negocio es otra afirmación |
| “Es una cripto anónima” | Cuentas, saldos y transacciones se consultan en abierto. Las cifras de este artículo salen justo de ahí |
| “Si sube el uso, sube la demanda de la moneda” | No se deduce del diseño, porque la comisión está marcada en dólares y el suministro es fijo |
| “Con una máquina potente entras en el consenso” | Los nodos de consenso forman una lista definida y publicada, con operador identificado |
Varias de estas correcciones desmontan exageraciones a favor del proyecto y otras desmontan exageraciones en contra, que también las hay.
13. Mi lectura del diseño y el punto que no consigo cerrar
Hasta aquí he intentado describir. En esta sección opino, y lo señalo para que se pueda descontar lo que quieras.
Me parece un diseño coherente. Si quieres que la certeza sobre el orden venga de una regla y no de una probabilidad, tienes que poder contar a los participantes, y para contarlos tienes que saber quiénes son. No conozco forma de tener lo primero sin lo segundo. Lo que valoro es que el intercambio no se disimula: el nombre de la organización que opera cada nodo está escrito en la respuesta de la API, sin necesidad de buscarlo. Un proyecto que quisiera ocultar el precio de su diseño no publicaría eso.
Dónde encaja y dónde no. Encaja bien en procesos donde importa que el orden y la hora dejen de ser provisionales, donde el coste tiene que caber en un presupuesto anual y donde saber con quién estás tratando es un requisito y no un estorbo. Ahí el servicio de consenso responde a una necesidad concreta y no a una moda. No encaja si lo que buscas es participación sin permiso y resistencia a que alguien te deje fuera; para eso esta red no es la respuesta. Se construyó otra cosa, y pedirle esto sería pedirle el diseño contrario.
La parte que no me cuadra es la moneda. Con la comisión marcada en dólares, el suministro cerrado y las recompensas saliendo del saldo de una cuenta con techo fijado por la gobernanza, no veo un camino claro por el que el crecimiento del uso llegue a quien tiene monedas. Puede que exista y que yo no lo esté viendo bien; me interesa más leer un argumento concreto sobre ese camino que otra lista de logotipos. Lo que sí tengo claro es que saber esto y aun así valorar la red positivamente es una postura defendible, y no saberlo es otra cosa.
Dónde puedo equivocarme, y dónde se equivoca la crítica habitual. Yo puedo estar infravalorando lo que significa tener un coste realmente previsible durante años, que para ciertos negocios es la variable que decide. Y en el otro sentido, la crítica de que esto es tecnología cerrada bajo patente se ha quedado vieja: la propiedad se compró, el código se publicó con licencia abierta y el núcleo pasó a una fundación externa, así que quien quiera discutir el grado de apertura tiene que discutir la lista de nodos de consenso, que es donde de verdad está el argumento.
14. Dónde encaja HBAR en tu recorrido: exchange, monedero y nodo
Bajemos al terreno. Si después de todo lo anterior quieres tener HBAR, el recorrido típico tiene tres tramos y en cada uno hay algo que comprobar.
El primero es la compra. Los pares que verifiqué en el momento de escribir aparecen en las tarjetas de abajo, junto a los códigos de registro de cada exchange. El segundo tramo es la custodia: si la idea es tener la moneda un tiempo largo o delegarla, tiene sentido sacarla del exchange a un monedero propio, con las llaves bajo tu control. El tercero es la delegación, que se hace desde la configuración de la cuenta apuntando a un nodo, con las condiciones que ya vimos.
Binance
Bybit
KuCoin
MEXC
Divulgación de afiliados: algunos enlaces son de socios. Podemos ganar una comisión sin coste adicional para ti. Esto no es asesoramiento de inversión.
Un apunte sobre lo que ves en pantalla: los productos, los pares y los servicios disponibles cambian según el exchange y según la región desde la que entras. No des por hecho lo que leas en ningún artículo, incluido este; abre tu propia pantalla y comprueba qué hay disponible en tu caso antes de mover dinero. Si estás comparando plataformas por primera vez, en la comparativa de exchanges están los criterios que uso, y en la guía de compra el proceso paso a paso, que es el mismo para cualquier moneda.
Y una advertencia sobre precios que quiero dejar por escrito: no hay en todo este artículo ninguna cifra de cotización, ni objetivo, ni previsión, y no es un descuido. Un perfil de red sirve para entender cómo está construido un diseño; para decidir qué haces con tu dinero hacen falta cosas que ningún artículo puede saber por ti, empezando por tu situación.
15. Diccionario mínimo para leer la documentación de Hedera
La documentación oficial está en inglés y usa un vocabulario propio que no siempre tiene una traducción asentada. Estos son los términos que hacen falta para leerla sin perderse, con la forma en que se suelen decir en español.
| Término | Qué significa |
|---|---|
| Hashgraph | El algoritmo de consenso de esta red, y también la estructura de datos que registra qué nodo recibió qué información y cuándo |
| Gossip about gossip | La forma de propagar información: cada mensaje entre nodos incluye, además de las transacciones, el historial de lo que ese nodo recibió antes y de quién |
| Votación virtual | Cada nodo deduce por cálculo qué habrían votado los demás, en vez de intercambiar votos por la red |
| aBFT | Tolerancia asíncrona a fallos bizantinos: la garantía se mantiene aunque menos de un tercio de los participantes falle o mienta, y sin suponer nada sobre el tiempo de entrega de los mensajes |
| Sello de tiempo de consenso | La hora que la red asigna a una transacción, calculada a partir de las marcas de tiempo de varios nodos y no fijada por uno solo |
| Staking delegado | Apuntar una cuenta a un nodo para que su saldo cuente como respaldo, sin mover ni inmovilizar las monedas |
| Tinybar | La unidad mínima: un HBAR equivale a 100.000.000 de tinybars. Es la unidad que devuelve la API |
| Servicio de consenso | El servicio que asigna orden y hora a mensajes procedentes de sistemas externos, sin almacenar los datos de esos sistemas |
| Nodo espejo | El nodo que sirve consultas de lectura y guarda el histórico. No participa en fijar el orden; es la fuente de todas las cifras de este artículo |
Con estos nueve términos se puede leer la documentación técnica del proyecto de principio a fin. Si te encuentras con alguno más y no aparece aquí, casi siempre será el nombre comercial de un servicio concreto y no un concepto del consenso.
Preguntas que quedan después de leer que no es una blockchain
Compara exchanges y comprueba en tu pantalla qué pares hay disponibles








