¿JAM se entregará en 12-20 meses? Tres desarrolladores principales revelan el modelo económico de M1, PoP y el futuro de ZK.

JAM, este nombre ha sido discutido durante mucho tiempo en la comunidad de Polkadot. Con Gavin Wood lanzando una serie de anuncios importantes en la Web3 Summit, las expectativas y dudas sobre JAM han alcanzado un nuevo máximo: ¿qué es realmente JAM? ¿Qué cambios traerá a Polkadot? ¿Cuánto falta para su lanzamiento oficial?

Para que la comunidad tenga una comprensión más completa, PolkaWorld invitó a tres invitados que participan directamente en el desarrollo central de JAM: Bryan del equipo de Acala, Junha, desarrollador de la implementación en Rust de JAM llamada “FastRoll”, y Boy Maas, desarrollador de la implementación en Zig “JAMZig” y cofundador del proyecto Polona.

Los tres invitados no solo participan profundamente en la implementación técnica de JAM, sino que también exploran su potencial desde diferentes ángulos: desde la implementación de clientes multilenguaje hasta la migración de toolchains cross-chain y el futuro de PVM, ellos representan el estado actual de JAM mejor que nadie.

En esta entrevista, nos llevarán a conocer el mundo de JAM desde su perspectiva de primera mano:

• ¿Qué significan realmente las importantes actualizaciones de JAM anunciadas por Gavin?
• ¿Cómo cambiarán el límite de tokens de JAM (π × 1,000 millones) y el mecanismo PoP (Proof of Personhood) el modelo económico de Polkadot?
• ¿Cuáles son los objetivos y avances técnicos del Milestone 1? ¿Cuándo se lanzará la testnet?
• ¿Cómo se combinará ZK (Zero-Knowledge Proofs) con JAM en el futuro?
• ¿Cómo influirán el mecanismo de gobernanza de JAM y el Comité Editorial del Gray Paper en la evolución a largo plazo del protocolo?

Si querés saber el futuro de JAM y cómo remodelará la infraestructura del ecosistema Polkadot, este episodio es imperdible.

Conociendo a los tres equipos de desarrollo de JAM

Kristen: Hola a todos, soy Kristen. Hoy tenemos a tres desarrolladores centrales de JAM, quienes están participando directamente en su desarrollo. Si seguís las novedades de PolkaWorld o Polkadot, ya sabrás que se está llevando a cabo la Web3 Summit, y Gavin anunció noticias importantes sobre JAM en el evento. La comunidad ya nos está enviando muchas preguntas, así que organizamos esta transmisión en vivo para que, a través de los invitados, la comunidad pueda entender a fondo lo que Gavin anunció sobre JAM en la Web3 Summit.

En la primera parte, quiero pedirles a los tres invitados que se presenten brevemente, expliquen en qué parte del proyecto JAM trabajan y el estado actual del desarrollo. Aunque algunos ya son viejos conocidos del programa, siempre hay nuevos espectadores, así que les pido que se presenten de nuevo. Empecemos por Junha.

Junha: Gracias por la invitación, Kristen. Hola a todos, soy Junha y es la primera vez que participo en este programa.

Actualmente estoy desarrollando la implementación en Rust del protocolo JAM, el proyecto se llama “FastRoll”. Por ahora, el equipo soy solo yo, así que soy un desarrollador independiente.

Llevo alrededor de un año con este proyecto, ahora estoy preparando la revisión del primer hito y ya empecé a avanzar en algunos trabajos de la segunda etapa.

Kristen: ¡Bienvenido, Junha! Ahora le pedimos a Bryan que se presente.

Bryan: Hola a todos, soy Bryan del equipo de Acala. Actualmente lidero un pequeño equipo que desarrolla otra implementación del protocolo JAM, el proyecto se llama “Boka”.

• También estamos finalizando la primera etapa y actualizando algunos componentes off-chain para preparar la segunda etapa.
• Además, acabamos de empezar a desarrollar el recompilador de PVM, pero aún estamos en una fase muy temprana, falta bastante para terminarlo.

Kristen: Gracias, Bryan, por volver al programa. Bryan fue nuestro primer invitado para hablar de JAM, me alegra que estés de vuelta. Por último, demos la bienvenida a Boy Maas, con quien ya hicimos una entrevista especial.

Boy Maas: Sí, sí, hola a todos, soy Boy Maas. Soy el desarrollador independiente de la implementación en Zig del protocolo JAM, nuestro cliente se llama “JAMZig”.

También soy cofundador de un proyecto en el ecosistema JAM, cuyo objetivo es migrar completamente el toolchain y la máquina virtual de Solana (SVM) a JAM. Ya completamos la fase de prueba de concepto, es decir, ya tenemos algunas funciones básicas en marcha.

¿JAM se entregará oficialmente en 12 a 20 meses?

Kristen: Bienvenido, Boy Maas. Polona es realmente un proyecto pionero, dedicado a atraer desarrolladores de Solana al ecosistema Polkadot, ¡una idea genial! Bienvenidos a los tres invitados.

La primera pregunta es para Boy Maas. Participaste en la Web3 Summit. Ya vimos en Twitter varias noticias sobre la charla de Gavin, pero quiero que nos cuentes desde tu perspectiva qué te llevaste del evento. ¿Viste la charla de Gavin? ¿Podés compartir qué información importante te quedó?

Boy Maas: Por supuesto, estar allí fue increíble. Pude conocer a muchos miembros de la comunidad Polkadot, hubo muchas charlas interesantes y se sentía el dinamismo y la energía positiva, lo que genera mucha expectativa para el futuro. Hoy es el último día y estoy ansioso por llevar esta experiencia de vuelta para seguir desarrollando.

Kristen: ¿Viste la charla de Gavin?

Boy Maas: Sí, la vi.

Kristen: ¿Hay algo que te haya llamado especialmente la atención? Vimos algunos textos en Twitter, pero queremos escucharlo desde la perspectiva de un desarrollador, explicado de manera sencilla.

Boy Maas: Claro. Gavin habló de muchas cosas. Es una persona con mucha visión y experiencia, así que sus decisiones e ideas nuevas influyen mucho en el rumbo de la comunidad.

Lo más importante es que anunció que la oferta total de tokens de JAM tendrá un límite fijo de “π por 1,000 millones” (π × 1,000,000,000), lo cual es muy relevante y traerá muchas consecuencias.

Otro punto clave es que intentó explicar con más claridad qué es JAM. JAM, en esencia, busca fortalecer y apoyar el ecosistema Polkadot, su objetivo es impulsar la infraestructura del ecosistema. Todos estamos en una etapa de exploración y adaptación: ¿qué es JAM? ¿Qué puede hacer? ¿Cómo colabora con la red principal de Polkadot? ¿Cómo se implementa?

Como desarrolladores, entendemos los detalles técnicos de JAM, pero entiendo que para la mayoría aún es difícil ver qué cambios traerá JAM. Todos intentan imaginar cómo será ese futuro impulsado por JAM.

Kristen: Suena muy interesante. También noté que Gavin mencionó que JAM se entregará oficialmente en 12 a 20 meses. Su proyecto Polona depende de ese cronograma, ¿no? ¿El avance de su desarrollo va en sincronía con el de JAM?

Boy Maas: Sí, Kristen, tenés razón. No planeamos tener todo listo para el lanzamiento de la testnet, pero con el cronograma anunciado, nuestro plan encaja perfectamente. Cuando la testnet de JAM esté disponible, podremos usarla de inmediato. Y cuando la red esté en funcionamiento, también estaremos listos para seguir el ritmo.

¿Qué es el M1 de JAM?

Kristen: Muy bien, me alegra escuchar esos avances. Ahora quiero preguntarle a Junha.

JAM publicó recientemente una actualización técnica importante y definió los objetivos de entrega del primer hito (milestone 1). Pero algunos oyentes no entienden bien qué es el milestone 1, qué incluye y en qué estado está. ¿Podés contarnos qué abarca el milestone 1? ¿Cómo va la testnet? ¿Cuándo creés que estará disponible?

Junha: Claro. Como mencionaste, el Gray Paper de JAM se actualizó recientemente a la versión 0.7.0. Gavin también dijo en su charla que, a partir de esta versión, la Polkadot Fellowship puede empezar a evaluar el milestone 1. Así que la mayoría de los equipos que desarrollan clientes de nodo JAM están preparándose para esa evaluación.

El objetivo del milestone 1 es entregar un cliente de nodo capaz de “importar bloques correctamente”, es decir, validar la lógica básica de ejecución de JAM.

En concreto, dado un conjunto de bloques (que pueden ser válidos o inválidos), el cliente debe identificar cuáles tienen el formato correcto. Para los bloques válidos, el cliente debe leer los datos externos, ejecutar la lógica de transición de estado (el núcleo de la blockchain) y finalmente generar un nuevo estado en la cadena. Porque una blockchain es, en esencia, una máquina de estados: dado un estado inicial, al importar bloques y ejecutar la lógica, se obtiene un estado posterior.

La evaluación del milestone 1 consiste en ver si la implementación del nodo puede, tras importar esos bloques, generar el estado posterior correcto.

El método de evaluación es directo: preparamos un lote de bloques de prueba y comparamos si los diferentes clientes generan exactamente el mismo estado posterior. Este resultado se puede resumir en una “vertical root”, así que la comparación es sencilla. Ya existe una herramienta de prueba llamada JAM Conformance Fuzzer, que puede generar automáticamente muchos bloques con datos aleatorios y probar si las implementaciones llegan al mismo root de estado.

Creo que es una buena oportunidad para encontrar bugs críticos y corregirlos a tiempo, sentando las bases para etapas más complejas.

Kristen: Entiendo, ¿cuándo creés que estará disponible la testnet?

Junha: ¿Te referís a la testnet de JAM? Algunos equipos ya intentaron interoperar con binarios compilados por ellos mismos, pero personalmente creo que una testnet realmente funcional estará madura recién después del milestone 2.

Porque el milestone 1 valida la lógica de transición de estado del nodo, pero eso no basta para operar una testnet completa. El milestone 2 evaluará si las implementaciones completaron el protocolo de comunicación de red (networking spec), pero esa parte aún no es estable ni está en el Gray Paper. Cuando la especificación de red se estabilice y las implementaciones la completen, se podrá probar la interoperabilidad entre nodos.

En ese momento será adecuado preparar la testnet. Claro, algunos equipos pueden intentar antes, pero mi plan es unirme después del milestone 2.

Kristen: Bien. ¿Creés que los anuncios de Gavin en la cumbre afectarán tu ritmo de desarrollo?

Junha: Creo que la mayoría de lo que mencionó está más orientado a la visión a largo plazo, así que a corto plazo no cambiará mucho mi plan. Ahora mi prioridad es terminar el milestone 1, calculo que me llevará unas semanas o un mes entregar una implementación completamente conforme. Así que por ahora, mi estrategia no cambia.

Obviamente, a uno o tres años, esos nuevos rumbos pueden influir, pero por ahora me concentro en el milestone 1.

¿Qué pasará si PoP reemplaza a NPoS?

Kristen: Entiendo, ¡gracias por compartir! Ahora una pregunta “dura” para Bryan, sobre la economía de los tokens. Sabemos que los desarrolladores suelen evitar opinar sobre modelos económicos, pero es una de las mayores preocupaciones de la comunidad. Gavin dijo en la cumbre que se usará PoP (Proof of Personhood) en lugar de NPoS, que las recompensas a validadores serán fijas y que habrá un mecanismo de halving anual para limitar la oferta total de DOT. Como desarrollador, ¿qué opinás de estos cambios? ¿Cuál creés que es el mayor impacto? ¿Estás a favor? ¿Tenés preocupaciones o sugerencias?

Bryan: Sí, es un cambio grande.

Repasando el contexto: ya sea Proof of Work (PoW), Proof of Stake (PoS) o el nuevo Proof of Personhood (PoP), todos estos mecanismos buscan proteger la seguridad de la red y evitar ataques como el double-spending o forks.

Cada mecanismo tiene su costo: PoW implica recompensas de bloque y mucho consumo eléctrico y computacional, PoS requiere recompensar a los stakers.

El nuevo PoP cambia mucho el sistema de recompensas. Polkadot usaba NPoS (Nominated Proof of Stake), que aunque no es tan caro como PoW, igual tiene el problema de que para mantener la seguridad hay que emitir nuevos tokens para recompensar a validadores y nominadores, lo que genera inflación.

El objetivo de PoP es bajar el costo de seguridad de la red, dejar de depender de incentivos económicos o castigos, y pasar a un sistema nuevo — aún no está claro cómo, pero la idea es “una persona, un voto”. Si esto funciona, hacer trampa será mucho más difícil y la seguridad será más fácil de garantizar, sin tener que pagar tantas recompensas en tokens.

Desde el punto de vista de la red, esto baja mucho el costo operativo, lo cual es bueno. Pero tiene un efecto secundario: antes muchos dependían de las recompensas de staking, y ahora ese modelo de ingresos desaparece. Aunque habrá nuevas formas de obtener tokens, la cantidad bajará mucho. Pero por otro lado, si la red gasta menos, el valor de tu token sube, así que en general lo veo positivo.

Además, esto puede beneficiar a DeFi. Si bajan las recompensas de staking, los usuarios pueden mover su capital a otros protocolos DeFi, como préstamos o liquidez, activando el ecosistema DeFi.

Obviamente, el impacto real depende de los detalles, y aunque tengamos el diseño completo, es difícil predecir todo. Pero personalmente, veo estos cambios de forma positiva.

Kristen: Creo que a corto plazo puede ser un golpe para los validadores, ya que sus ingresos bajarán mucho. ¿Creés que esto puede causar problemas al principio?

Bryan: Depende de cómo se haga la transición. No va a cambiar todo de un día para otro, será gradual, como el halving anual de la oferta de tokens. No vamos a cortar la inflación a cero el primer día, sino que se reducirá año a año, dando tiempo a todos para adaptarse y ajustar estrategias.

Tenemos que asegurar la seguridad de la red, que los validadores al menos cubran sus costos y tengan algo de ganancia, y que haya incentivos para nominar y elegir buenos validadores. Eso no cambia, solo queremos dejar de pagar recompensas tan altas. Así que habrá cambios, pero esperamos que el nuevo modelo económico minimice el impacto.

¿Qué es zkJAM?

Kristen: Es cierto, la comunidad está dividida. Al principio todos pedían “menos inflación”, ahora que vamos hacia la deflación, algunos se quejan. Creo que es un buen rumbo, gracias por compartir tu visión tan profunda.

Ahora hablemos de un tema técnico: ZKJAM. Vi este término en la presentación de Gavin, parece algo conceptual. Pero Zero-Knowledge Proofs (ZK) es muy popular en Web3, muchos dicen que ZK es la solución definitiva para Rollups y escalabilidad. Si en el futuro ZK y JAM se combinan, ¿cómo sería? Me gustaría escuchar sus opiniones. Junha, empezá vos.

Junha: Bien. Gavin comparó JAM en su charla con una “supercomputadora bare metal descentralizada”, y los servicios sobre ella serían como sistemas operativos en el hardware, como Windows o macOS.

Si en el futuro ZK se integra en JAM, desde el punto de vista de los desarrolladores de servicios o aplicaciones, no habrá un cambio “disruptivo”, la experiencia de desarrollo y usuario debería ser básicamente igual.

Aun si el mecanismo de seguridad de JAM pasa del modelo actual “basado en auditoría y re-ejecución” a uno “basado en pruebas ZK”, mientras la actualización esté bien verificada y funcione mejor, vale la pena adoptarla.

Así que si ZK y JAM se adaptan bien y es mejor que el sistema actual, la actualización es viable y la experiencia no cambiará mucho.

Kristen: Gracias por compartir. Quizás algunos oyentes se marearon con los términos técnicos, pero no se preocupen, habrá una versión en español para repasar y entender. Ahora, Bryan, ¿qué opinás?

Bryan: Creo que hay que distinguir dos conceptos: JAM como infraestructura que soporta Rollups seguros con ZK, y JAM usando ZK para su propia seguridad. Son cosas distintas.

Con el PVM de JAM, cualquier algoritmo o arquitectura relacionada con ZK, como nuevos protocolos ZK-Rollup, puede desplegarse como un servicio en JAM. Eso es fácil de lograr.

Pero si JAM quiere usar ZK para su propia seguridad, eso requiere mucha investigación avanzada y optimización de algoritmos. Por ahora, eso está en la frontera de la investigación. Depende de la situación: quizás hoy los algoritmos no son lo suficientemente rápidos o baratos, pero mañana alguien inventa uno 100 veces más eficiente y todo cambia.

Así que si en el futuro aparece una integración ZK realmente útil que haga JAM más seguro, por supuesto que la apoyaría.

Kristen: Ojalá haya avances en ese campo. Boy Maas, como desarrollador experimentado, ¿qué pensás?

Boy Maas: Creo que Bryan y Junha ya lo explicaron muy bien. Me gusta JAM porque es un sistema muy pragmático. Sus decisiones de diseño buscan que el sistema funcione y ejecute cálculos. Como dijo Bryan, hoy hacer todo con ZK es demasiado caro e irreal. Así que imagino que en el futuro se usará un “modelo híbrido”, con auditoría tradicional y ZK en paralelo.

Por ahora, ZK es demasiado costoso e impráctico, pero en los próximos 12 meses a 5 años, el campo ZK cambiará mucho. Si ZK se vuelve eficiente, será una tecnología muy atractiva y podría redefinir la seguridad y arquitectura del sistema.

Pero por ahora, el modelo híbrido es más realista: mantiene la practicidad y permite que las aplicaciones que realmente necesitan seguridad ZK la usen.

JAM creará un Comité Editorial del Gray Paper

Kristen: Gracias por sus opiniones. Ahora pasemos al siguiente tema: la gobernanza de JAM.

Gavin seguirá siendo el editor principal del Gray Paper y anunció la creación de un “Comité Editorial del Gray Paper”, formado por contribuyentes con experiencia técnica profunda en JAM, que decidirán juntos las actualizaciones, prioridades y decisiones clave del protocolo. Como desarrolladores, ¿creen que este modelo de gobernanza es viable? ¿Puede desviarse de la intención original? ¿Cómo se debería manejar si eso pasa? Empecemos por Boy Maas.

Boy Maas: Creo que es una pregunta muy relevante. En un campo tan técnico y profesional, tener un comité para actualizar el Gray Paper es razonable y necesario. Quienes tomen esas decisiones deben entender profundamente los principios de JAM y tener experiencia práctica para juzgar sabiamente. Que Gavin lidere el comité es lógico, así que apoyo totalmente este modelo de gobernanza.

Kristen: ¿Entonces creés que es bueno que un equipo profesional decida el protocolo colectivamente?

Boy Maas: Sí, totalmente de acuerdo.

Kristen: Bien, Bryan, ¿qué opinás?

Bryan: En realidad, todos los proyectos son gobernados por algún tipo de “comité”, solo que varía el tamaño y los miembros. La diferencia es si el proceso de gobernanza está claramente definido.

Creo que definir el proceso de gobernanza es un avance, al menos todos saben cómo se toman las decisiones y eso aumenta la transparencia y facilita mejorar el proceso en el futuro. Si no hay reglas, no hay cómo mejorarlas.

El contenido del Gray Paper es muy complejo, casi todos los desarrolladores de JAM lo han leído varias veces en diferentes versiones. Pero honestamente, quizás solo Gavin lo entiende al 100%, o ni siquiera él cada detalle. Ahora hay mucha gente corrigiendo errores, fórmulas, lógica, y eso ya es un proceso colaborativo.

Así que creo que solo quienes tienen años de experiencia en este campo deberían modificar el Gray Paper. Un pequeño cambio puede tener grandes consecuencias. Esto afecta el futuro de Web3, incluso de Internet, y la seguridad de muchos activos, así que hay que ser muy cuidadosos. La transparencia y apertura son clave. Todos pueden sugerir, pero hay que demostrar que entendés tu sugerencia, si no, el ruido tapa las ideas útiles.

Kristen: Entonces creés que el comité debe tener reglas sobre quién puede unirse, cómo organizarse, etc. Porque todos tienen opiniones y sin reglas es fácil que haya desacuerdos o desviaciones.

Bryan: Por eso necesitamos smart contracts y procesos claros, todo por escrito. Si las reglas están claras, cualquiera puede supervisar y todo es transparente, así es menos probable desviarse. Si todo se hace a puertas cerradas, nadie sabe qué pasa y es más fácil perder el rumbo. La transparencia es clave, y si el proceso puede ser forzado por smart contracts, el mecanismo puede durar a largo plazo.

Kristen: Entiendo, recuerdo que la comunidad de Bitcoin también tiene un comité de desarrolladores para avanzar.

Bryan: Sí, Bitcoin tiene un grupo de desarrolladores centrales, pero la decisión final se toma por fork: la cadena con más poder de cómputo gana.

Kristen: Entiendo, gracias por la explicación. Por último, escuchemos la opinión de Junha.

Junha: Creo que crear un comité editorial es un paso natural y significativo. JAM es un proyecto especial: antes de tener software funcional, se publicó una especificación técnica completa (Gray Paper). Ese documento tiene muchas fórmulas matemáticas para definir el comportamiento del sistema. Publicar la documentación antes que el desarrollo busca mayor descentralización y resiliencia.

Por eso, el Gray Paper ya fue revisado muchas veces y seguirá cambiando incluso después de la versión 1.0.

A medida que más equipos implementen JAM y monten testnets, seguro encontraremos partes a optimizar para mejorar la eficiencia o viabilidad. Así que, por la naturaleza de JAM, el Gray Paper seguirá evolucionando incluso tras el lanzamiento en mainnet, quizás incluso haya hard forks.

En ese contexto, que varias personas desarrollen la especificación es claramente mejor que depender de un solo autor.

Como dijo Bryan, la transparencia es clave y el proceso de decisión del comité debe ser público. También espero que más equipos que usen JAM participen en la revisión y feedback del documento, no solo “creer que Gavin tiene razón”. Participar activamente ayuda a encontrar mejoras. Es un buen comienzo y tiene sentido para JAM.

Quizás subestimamos lo que JAM puede aportar a blockchain

Kristen: Bien, es un gran comienzo. Si todo el proceso es transparente, será genial. Gracias por sus aportes, creo que cubrimos todos los temas de hoy.

Para cerrar, ¿quieren agregar algo más? Sobre JAM, la Web3 Summit, ¿algo que no hayan dicho? Empecemos por Bryan.

Bryan: No tengo mucho más para agregar. JAM es una infraestructura de base, es importante pero no lo es todo. Lo realmente importante son los servicios y aplicaciones que se construyan sobre JAM: los usuarios no usarán JAM directamente, sino los servicios basados en JAM.

Así que el lanzamiento de JAM es solo el primer paso para lograr el objetivo final. Debemos enfocarnos en los servicios y aplicaciones que corran sobre JAM, eso es lo que realmente impacta a los usuarios. Hay mucho por hacer, y no debemos limitarnos solo al protocolo JAM, sino también a todo lo que se construya encima.

Kristen: Gracias. Boy Maas, ¿algo más sobre Polona o JAM?

Boy Maas: Claro. Primero, sobre JAM. Recuerdo que en Lisboa, Gavin dio una charla sobre JAM. En ese momento sentí que quizás estamos subestimando lo que esta plataforma puede aportar a la comunidad blockchain.

La “capacidad” y flexibilidad que ofrece JAM no la ha logrado ninguna blockchain antes. Creo que es un hito en la historia de blockchain, especialmente por las nuevas aplicaciones que puede soportar, es muy único.

Además, nuestro proyecto Polona avanza rápido, ya tenemos una prueba de concepto (PoC) corriendo en JAM. Ya migramos el SVM de Solana a PVM, así que ahora podés poner bytecode de Solana en JAM y ejecutarlo, incluyendo llamadas entre contratos, todo funciona, es genial. Eso muestra el poder de JAM.

Kristen: Genial, ¡gracias! Por último, Junha, ¿algo para agregar?

Junha: Espero que más gente se interese por JAM, Polkadot y el Gray Paper. Realmente quiero conectar con más personas y compartir ideas.

El cliente de JAM aún está en desarrollo, así que no hay muchos ejemplos de aplicaciones “terminadas”. El equipo de Gavin mostró algunos demos, pero aún no hay muchos casos reales que convenzan a la gente de lo que el sistema puede hacer.

Pero creo que si te interesa la filosofía detrás de Web3 y querés empujar los límites de la industria, JAM es un proyecto que vale la pena estudiar a fondo. Yo he estado trabajando solo en esto, así que realmente quiero conocer más gente con intereses similares, aunque sea para leer el Gray Paper y debatir. Ojalá podamos compartir ideas y construir cosas nuevas juntos, especialmente después de entregar el nodo.

Kristen: Bien, gracias por compartir y muchas gracias a los invitados por sus excelentes opiniones y perspectivas. Gracias a todos los oyentes por participar, les recomiendo seguir a nuestros invitados en Twitter, pueden encontrar sus cuentas en los anuncios de PolkaWorld. Seas usuario o desarrollador, estar al tanto de los avances de JAM es muy valioso. ¡Gracias por escuchar, nos vemos la próxima! ¡Chau!