¡Saludos, comunidad! 🙌
Queremos compartirles algunas de las actualizaciones que incluye el próximo Hardfork de Hive: **Hardfork 28 (HF28)** / versión 1.28.0.
Este HF28 se ha estado trabajando desde hace bastante tiempo. Trae cambios técnicos muy importantes, pero también implica un cambio directo para todos los usuarios que votamos contenido en Hive, y ahí es donde nos vamos a enfocar primero.
---
Antes de comenzar, queremos aclarar rápidamente qué es un **Hardfork** en Hive.
>Un **Hardfork** (HF) en Hive consiste en una actualización coordinada de la red en la que se modifican las reglas de consenso del blockchain. En una hora acordada, los testigos y los nodos actualizan su software a una nueva versión. Desde ese bloque marcado, toda la red sigue esas nuevas reglas.
En pocas palabras: es cuando Hive "actualiza su versión" y, desde ese momento, solo las cuentas y los nodos que están actualizados permanecen en la cadena válida; los que no actualizan quedan en una versión antigua e incompatible.
También es importante señalar que este Hardfork, **HF28**, tiene como fecha de activación inicial el **19 de noviembre de 2025 a las 13:00:00 UTC** (miércoles 19 de noviembre). Esto será aproximadamente en dos semanas y media a partir de hoy.
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
## 1. Cambios en la curación (Voting Power / Voting Mana)
Hasta ahora, el valor de tu voto en dólares bajaba más rápido de lo que debería. Cada voto gastaba poder de voto (Voting Power / mana), y los votos seguidos se volvían más débiles, incluso si usabas el mismo porcentaje de voto. Eso hacía que una parte de tu poder de voto real fuera, en la práctica, imposible de ejercer.
El equipo de desarrollo de Hive (CoreDev) lo explica así:
> "El problema es que los votos consecutivos con el mismo peso se van debilitando. Eso hace que la parte 'profunda' del mana resulte inutilizable y termina por alejar el poder real del voto de la intención del curador."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
---
¿Qué cambia con HF28?
Antes:
* Cada voto iba "debilitando" tu poder o el valor de tu voto.
* Tus últimos votos del día valían mucho menos ($).
Después de HF28:
* Tu voto tendrá el **mismo valor relativo** mientras tengas mana disponible.
* **Podrás usar TODO tu Voting Power hasta 0%.**
* Por fin se vuelve realidad eso de "50 votos al 100% en una ventana de 5 días de recarga".
El equipo de desarrollo lo resume así:
> "Se simplifica el manejo del poder de voto. Los usuarios podrán usar todo su mana de voto hasta que llegue a cero."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
En resúmen:
* Tus votos se vuelven cada vez más débiles a medida que votas.
* Lo que tú quieres votar vale lo que esperas que valga.
* Es más transparente para creadores y curadores.
Para nosotros, como curadores, esto es enorme. Vamos a ver en la práctica qué pasa con la distribución de recompensas y con las estrategias de curación manual, pero de entrada esto suena muy positivo: **más claridad y menos castigo invisible para quienes votan de forma activa.**
## 2. Límites de edición de votos
Se eliminan ciertas restricciones para editar los votos en publicaciones.
> "Se eliminan los límites de edición de votos en los posts."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
## 3. Transferencias recurrentes
Actualmente puedes programar pagos recurrentes (por ejemplo, enviar HBD automáticamente cada cierto tiempo). Con HF28 esto mejora:
* Ahora será posible realizar **múltiples transferencias recurrentes** entre el mismo emisor y el mismo receptor.
> "Se permiten múltiples transferencias recurrentes entre el mismo par emisor/receptor."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto es útil para pagos internos de proyectos, recompensas automáticas, gestión de tesorería, etc.
## 4. Tamaño de bloque
Actualmente, la red de Hive tiene un límite efectivo de aproximadamente 64 KB por bloque (65,536 bytes). Se ha decidido fijar el tamaño del bloque en **2 MB**, lo que permite procesar más transacciones por bloque y aumenta la capacidad total.
Este cambio representa una mejora de 32 veces (ya que 2 MB equivale a 32 veces 64 KB). Esto significa que se podrán incluir muchas más transacciones, publicaciones, votos, transferencias, juegos en cadena, NFTs, etc., sin que la red se congestione durante los períodos de alta demanda.
## 5. Tiempo de expiración de transacciones
El período de expiración de las transacciones (el tiempo máximo que tienen antes de que la red las rechace por ser demasiado antiguas) se prolongará. Esto incrementa la **resistencia en conexiones inestables o lentas**. En resumen: si tu conexión es regular, tus transacciones podrán tener un mayor margen de error antes de fallar.
## 6. Cambios en HBD dentro del DHF / Inflación
El HBD dentro del Fondo de Desarrollo (el DHF / DAO de Hive) **ya no se incluirá en ciertos cálculos de inflación**.
Este cambio, que es más técnico y contable, en resumen:
* Ofrece una medición más precisa de la inflación real.
* Previene que el HBD estacionado en el fondo de desarrollo afecte la inflación.
## 7. Autoridades y firmas
Hive también está ajustando los métodos de validación de firmas y de permisos de autoridad (posting / active / owner), mejorando la seguridad y la facilidad de uso.
### a) Verificación de autoridad más estricta
* La autoridad de `posting` ya no podrá acceder por error a permisos que no le corresponden.
* Se refuerza la diferenciación adecuada entre los permisos de `posting`, `active` y `owner`.
### b) Más flexibilidad en firmas
> "Se permiten firmas redundantes (aunque no tengan efecto). Además, si una transacción requiere distintos tipos de autoridad (por ejemplo, `posting` y `active`), esas firmas pueden combinarse en una sola transacción."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto significa que habrá:
* Menor fricción para herramientas, frontends y servicios que realizan varias operaciones simultáneamente.
* Mejor experiencia para usuarios avanzados e integraciones… sin bajar la seguridad.
## 8. Propuestas (Proposal Voting)
Si intentas votar una propuesta inválida en el sistema de propuestas financiadas por el DHF, esa transacción fallará de inmediato.
> "Votar por propuestas inválidas hará que la transacción falle."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto contribuye a depurar el sistema de gobernanza y a prevenir el ruido o los abusos.
## 9. Cambios para nodos / testigos / infraestructura
Esto es más para testigos, nodos de API y gente que gestiona infraestructura, pero lo mencionamos porque @aliento también es testigo y estamos preparándonos para operar nuestro nodo de API. HF28 trae cambios internos fuertes.
### a) Replay necesario
> "Actualizar a la versión 1.28.0 normalmente va a requerir un 'replay' completo del nodo debido a cambios en el formato interno del estado de `hived` y en sus estructuras de datos."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Traducción:
* Los testigos y operadores casi seguros tendrán que reconstruir el estado desde cero al actualizar.
### b) `block-log-split`
Hive introduce la opción `block-log-split`.
Resumen:
* Ahora, el historial de bloques (block_log) puede dividirse automáticamente en archivos por partes (cada parte contiene ~1 millón de bloques), en lugar de un único archivo gigante.
* Esto permite:
* Ahorrar espacio en disco.
* Mover las partes viejas del historial a discos más baratos.
* Compartir esas partes entre varios nodos.
* Ejecutar los nodos en modo "podado" (pruned), guardando únicamente lo más reciente.
> "Dividir el block_log en archivos por partes permite reubicar esos archivos en distintos sistemas de discos, compartir la mayor parte del historial entre varios nodos y operar en modo podado para ahorrar espacio. En modo podado, el nodo guarda menos historia antigua, pero también tiene menos capacidad para servir bloques antiguos a otros nodos o a APIs históricas."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Importante para operadores:
Durante la primera conversión (cuando pasas de un block_log gigante a bloques divididos), temporalmente puedes necesitar casi el doble de espacio disponible mientras se realiza la separación.
### c) `comments-rocksdb-path`
Ahora, los datos de comentarios pueden almacenarse en una base de datos externa (RocksDB) en un directorio separado del `shared_memory_file`.
> "Esto permite colocar los datos de comentarios en otra ruta y así reducir la cantidad de RAM / espacio en disco rápido que necesitas durante el replay o la sincronización."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto sginifica que habrá:
* Menos presión en la RAM.
* Más control sobre dónde colocas qué datos.
### d) Control más limpio para parar el nodo en un bloque específico
* `stop-replay-at-block` ahora se llama `stop-at-block`.
* También existe `exit-at-block`, que indica al nodo que se apague automáticamente al llegar a cierto bloque.
Esto ayuda mucho en pruebas, auditorías y migraciones controladas.
---
| 🚀 I. Hardfork 28 (HF28) - Cambios de Consenso del Protocolo |
| ---------------------------------------------------------------------------------------------------------------------------- |
| Estos cambios fueron implementados en la rama 1.27.x y están programados para activarse cuando se alcance el bloque HF28. |
| Área / Función | Cambio / Detalles | Referencia técnica |
|------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|
| Límite de Tamaño de Bloque | El tamaño del bloque, configurable por los testigos, está limitado a **2 MB**. | [Merge Request 1357](https://gitlab.syncad.com/hive/hive/-/merge_requests/1357) |
| Expiración de Transacciones | Se **aumenta el tiempo de expiración de las transacciones** para mejorar la resiliencia de la red. | [Merge Request 1383](https://gitlab.syncad.com/hive/hive/-/merge_requests/1383) |
| Inflación del Tesoro en HBD | El HBD del Tesoro DHF **se excluye de los cálculos de inflación**. | [Merge Request 1467](https://gitlab.syncad.com/hive/hive/-/merge_requests/1467) |
| Verificación de Autoridad | Se aplica una coincidencia de autoridad más estricta (por ejemplo: una autoridad `active` ya no puede cumplir un requisito que debería ser de nivel `posting`). | [Merge Request 1408](https://gitlab.syncad.com/hive/hive/-/merge_requests/1408), [Issue 716](https://gitlab.syncad.com/hive/hive/-/issues/716) |
| Flexibilidad de Firmas | Se permiten firmas redundantes (aunque sean ineficaces). Además, si una transacción requiere diferentes tipos de autoridad (`owner` / `active` / `posting`) por operaciones mezcladas, esas firmas se pueden combinar en **una sola transacción**. | [Merge Request 1420](https://gitlab.syncad.com/hive/hive/-/merge_requests/1420) |
| Cambios en el Poder de Voto | Gestión del poder de voto simplificada. | [Issue 609](https://gitlab.syncad.com/hive/hive/-/issues/609) |
| Límites de Edición de Voto | Se eliminan los límites para editar votos en publicaciones. | [Issue 458](https://gitlab.syncad.com/hive/hive/-/issues/458) |
| Transferencias Recurrentes | Se permiten **múltiples transferencias recurrentes** para el mismo par emisor/receptor. | [Issue 382](https://gitlab.syncad.com/hive/hive/-/issues/382) |
| Votación de Propuestas | Votar una propuesta inválida hará que la transacción falle. | [Merge Request 1460](https://gitlab.syncad.com/hive/hive/-/merge_requests/1460) |
## Fuente de la tabla:
- [Fuente](https://gitlab.syncad.com/hive/hive/-/releases#-i-hardfork-28-hf28---protocol-consensus-changes)
## ¿Y ahora qué?
Para nosotros en Aliento, lo más relevante a corto plazo es el **cambio en el sistema de votos / curación**, porque afecta directamente:
* el valor de los votos que damos a creadores,
* la forma de apoyar contenido nuevo,
* y la manera en que se distribuyen las recompensas.
También nos interesan:
* las transferencias recurrentes múltiples (para automatizar recompensas / pagos internos),
* y los cambios de infraestructura para los testigos (porque @aliento es testigo de Hive y tenemos que estar listos para la actualización).
Nos gustaría saber de ustedes:
**¿Qué cambio les parece más importante?**
¿Quieren que hagamos una sesión de preguntas y respuestas en Discord/Telegram?
¿O prefieren un video corto en 3Speak que explique solo el tema del Voting Power con ejemplos reales?
Los leemos.
## 1. Cambios en la curación (Voting Power / Voting Mana)
Hasta ahora, el valor de tu voto en dólares bajaba más rápido de lo que debería. Cada voto gastaba poder de voto (Voting Power / mana), y los votos seguidos se volvían más débiles, incluso si usabas el mismo porcentaje de voto. Eso hacía que una parte de tu poder de voto real fuera, en la práctica, imposible de ejercer.
El equipo de desarrollo de Hive (CoreDev) lo explica así:
> "El problema es que los votos consecutivos con el mismo peso se van debilitando. Eso hace que la parte 'profunda' del mana resulte inutilizable y termina por alejar el poder real del voto de la intención del curador."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
---
¿Qué cambia con HF28?
Antes:
* Cada voto iba "debilitando" tu poder o el valor de tu voto.
* Tus últimos votos del día valían mucho menos ($).
Después de HF28:
* Tu voto tendrá el **mismo valor relativo** mientras tengas mana disponible.
* **Podrás usar TODO tu Voting Power hasta 0%.**
* Por fin se vuelve realidad eso de "50 votos al 100% en una ventana de 5 días de recarga".
El equipo de desarrollo lo resume así:
> "Se simplifica el manejo del poder de voto. Los usuarios podrán usar todo su mana de voto hasta que llegue a cero."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
En resúmen:
* Tus votos se vuelven cada vez más débiles a medida que votas.
* Lo que tú quieres votar vale lo que esperas que valga.
* Es más transparente para creadores y curadores.
Para nosotros, como curadores, esto es enorme. Vamos a ver en la práctica qué pasa con la distribución de recompensas y con las estrategias de curación manual, pero de entrada esto suena muy positivo: **más claridad y menos castigo invisible para quienes votan de forma activa.**
## 2. Límites de edición de votos
Se eliminan ciertas restricciones para editar los votos en publicaciones.
> "Se eliminan los límites de edición de votos en los posts."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
## 3. Transferencias recurrentes
Actualmente puedes programar pagos recurrentes (por ejemplo, enviar HBD automáticamente cada cierto tiempo). Con HF28 esto mejora:
* Ahora será posible realizar **múltiples transferencias recurrentes** entre el mismo emisor y el mismo receptor.
> "Se permiten múltiples transferencias recurrentes entre el mismo par emisor/receptor."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto es útil para pagos internos de proyectos, recompensas automáticas, gestión de tesorería, etc.
## 4. Tamaño de bloque
Actualmente, la red de Hive tiene un límite efectivo de aproximadamente 64 KB por bloque (65,536 bytes). Se ha decidido fijar el tamaño del bloque en **2 MB**, lo que permite procesar más transacciones por bloque y aumenta la capacidad total.
Este cambio representa una mejora de 32 veces (ya que 2 MB equivale a 32 veces 64 KB). Esto significa que se podrán incluir muchas más transacciones, publicaciones, votos, transferencias, juegos en cadena, NFTs, etc., sin que la red se congestione durante los períodos de alta demanda.
## 5. Tiempo de expiración de transacciones
El período de expiración de las transacciones (el tiempo máximo que tienen antes de que la red las rechace por ser demasiado antiguas) se prolongará. Esto incrementa la **resistencia en conexiones inestables o lentas**. En resumen: si tu conexión es regular, tus transacciones podrán tener un mayor margen de error antes de fallar.
## 6. Cambios en HBD dentro del DHF / Inflación
El HBD dentro del Fondo de Desarrollo (el DHF / DAO de Hive) **ya no se incluirá en ciertos cálculos de inflación**.
Este cambio, que es más técnico y contable, en resumen:
* Ofrece una medición más precisa de la inflación real.
* Previene que el HBD estacionado en el fondo de desarrollo afecte la inflación.
## 7. Autoridades y firmas
Hive también está ajustando los métodos de validación de firmas y de permisos de autoridad (posting / active / owner), mejorando la seguridad y la facilidad de uso.
### a) Verificación de autoridad más estricta
* La autoridad de `posting` ya no podrá acceder por error a permisos que no le corresponden.
* Se refuerza la diferenciación adecuada entre los permisos de `posting`, `active` y `owner`.
### b) Más flexibilidad en firmas
> "Se permiten firmas redundantes (aunque no tengan efecto). Además, si una transacción requiere distintos tipos de autoridad (por ejemplo, `posting` y `active`), esas firmas pueden combinarse en una sola transacción."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto significa que habrá:
* Menor fricción para herramientas, frontends y servicios que realizan varias operaciones simultáneamente.
* Mejor experiencia para usuarios avanzados e integraciones… sin bajar la seguridad.
## 8. Propuestas (Proposal Voting)
Si intentas votar una propuesta inválida en el sistema de propuestas financiadas por el DHF, esa transacción fallará de inmediato.
> "Votar por propuestas inválidas hará que la transacción falle."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto contribuye a depurar el sistema de gobernanza y a prevenir el ruido o los abusos.
## 9. Cambios para nodos / testigos / infraestructura
Esto es más para testigos, nodos de API y gente que gestiona infraestructura, pero lo mencionamos porque @aliento también es testigo y estamos preparándonos para operar nuestro nodo de API. HF28 trae cambios internos fuertes.
### a) Replay necesario
> "Actualizar a la versión 1.28.0 normalmente va a requerir un 'replay' completo del nodo debido a cambios en el formato interno del estado de `hived` y en sus estructuras de datos."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Traducción:
* Los testigos y operadores casi seguros tendrán que reconstruir el estado desde cero al actualizar.
### b) `block-log-split`
Hive introduce la opción `block-log-split`.
Resumen:
* Ahora, el historial de bloques (block_log) puede dividirse automáticamente en archivos por partes (cada parte contiene ~1 millón de bloques), en lugar de un único archivo gigante.
* Esto permite:
* Ahorrar espacio en disco.
* Mover las partes viejas del historial a discos más baratos.
* Compartir esas partes entre varios nodos.
* Ejecutar los nodos en modo "podado" (pruned), guardando únicamente lo más reciente.
> "Dividir el block_log en archivos por partes permite reubicar esos archivos en distintos sistemas de discos, compartir la mayor parte del historial entre varios nodos y operar en modo podado para ahorrar espacio. En modo podado, el nodo guarda menos historia antigua, pero también tiene menos capacidad para servir bloques antiguos a otros nodos o a APIs históricas."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Importante para operadores:
Durante la primera conversión (cuando pasas de un block_log gigante a bloques divididos), temporalmente puedes necesitar casi el doble de espacio disponible mientras se realiza la separación.
### c) `comments-rocksdb-path`
Ahora, los datos de comentarios pueden almacenarse en una base de datos externa (RocksDB) en un directorio separado del `shared_memory_file`.
> "Esto permite colocar los datos de comentarios en otra ruta y así reducir la cantidad de RAM / espacio en disco rápido que necesitas durante el replay o la sincronización."
Fuente: [https://gitlab.syncad.com/hive/hive/-/releases](https://gitlab.syncad.com/hive/hive/-/releases)
Esto sginifica que habrá:
* Menos presión en la RAM.
* Más control sobre dónde colocas qué datos.
### d) Control más limpio para parar el nodo en un bloque específico
* `stop-replay-at-block` ahora se llama `stop-at-block`.
* También existe `exit-at-block`, que indica al nodo que se apague automáticamente al llegar a cierto bloque.
Esto ayuda mucho en pruebas, auditorías y migraciones controladas.
---
| 🚀 I. Hardfork 28 (HF28) - Cambios de Consenso del Protocolo |
| ---------------------------------------------------------------------------------------------------------------------------- |
| Estos cambios fueron implementados en la rama 1.27.x y están programados para activarse cuando se alcance el bloque HF28. |
| Área / Función | Cambio / Detalles | Referencia técnica |
|------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|
| Límite de Tamaño de Bloque | El tamaño del bloque, configurable por los testigos, está limitado a **2 MB**. | [Merge Request 1357](https://gitlab.syncad.com/hive/hive/-/merge_requests/1357) |
| Expiración de Transacciones | Se **aumenta el tiempo de expiración de las transacciones** para mejorar la resiliencia de la red. | [Merge Request 1383](https://gitlab.syncad.com/hive/hive/-/merge_requests/1383) |
| Inflación del Tesoro en HBD | El HBD del Tesoro DHF **se excluye de los cálculos de inflación**. | [Merge Request 1467](https://gitlab.syncad.com/hive/hive/-/merge_requests/1467) |
| Verificación de Autoridad | Se aplica una coincidencia de autoridad más estricta (por ejemplo: una autoridad `active` ya no puede cumplir un requisito que debería ser de nivel `posting`). | [Merge Request 1408](https://gitlab.syncad.com/hive/hive/-/merge_requests/1408), [Issue 716](https://gitlab.syncad.com/hive/hive/-/issues/716) |
| Flexibilidad de Firmas | Se permiten firmas redundantes (aunque sean ineficaces). Además, si una transacción requiere diferentes tipos de autoridad (`owner` / `active` / `posting`) por operaciones mezcladas, esas firmas se pueden combinar en **una sola transacción**. | [Merge Request 1420](https://gitlab.syncad.com/hive/hive/-/merge_requests/1420) |
| Cambios en el Poder de Voto | Gestión del poder de voto simplificada. | [Issue 609](https://gitlab.syncad.com/hive/hive/-/issues/609) |
| Límites de Edición de Voto | Se eliminan los límites para editar votos en publicaciones. | [Issue 458](https://gitlab.syncad.com/hive/hive/-/issues/458) |
| Transferencias Recurrentes | Se permiten **múltiples transferencias recurrentes** para el mismo par emisor/receptor. | [Issue 382](https://gitlab.syncad.com/hive/hive/-/issues/382) |
| Votación de Propuestas | Votar una propuesta inválida hará que la transacción falle. | [Merge Request 1460](https://gitlab.syncad.com/hive/hive/-/merge_requests/1460) |
## Fuente de la tabla:
- [Fuente](https://gitlab.syncad.com/hive/hive/-/releases#-i-hardfork-28-hf28---protocol-consensus-changes)
## ¿Y ahora qué?
Para nosotros en Aliento, lo más relevante a corto plazo es el **cambio en el sistema de votos / curación**, porque afecta directamente:
* el valor de los votos que damos a creadores,
* la forma de apoyar contenido nuevo,
* y la manera en que se distribuyen las recompensas.
También nos interesan:
* las transferencias recurrentes múltiples (para automatizar recompensas / pagos internos),
* y los cambios de infraestructura para los testigos (porque @aliento es testigo de Hive y tenemos que estar listos para la actualización).
Nos gustaría saber de ustedes:
**¿Qué cambio les parece más importante?**
¿Quieren que hagamos una sesión de preguntas y respuestas en Discord/Telegram?
¿O prefieren un video corto en 3Speak que explique solo el tema del Voting Power con ejemplos reales?
Los leemos.
¡Somos Aliento, creando valor en la Web3! 🚀
@Aliento - Linktree - https://aliento.blog/ |
| Discord | Canal de Telegram | Grupo de Telegram | Blog en Hive |
| X / Twitter |
