Ingeniero de Ripple Revela por qué el Proyecto Codius Fracasó Hace Años

bitcoinistPublicado a 2026-03-10Actualizado a 2026-03-10

Resumen

El ex ingeniero senior de Ripple, Steven Zeiler, reavivó el debate sobre el fracaso del proyecto Codius, afirmando que la falta de un token nativo impidió su adopción. Según Zeiler, sin un activo para incentivar a los usuarios tempranos, la plataforma de computación descentralizada no logró ganar tracción, a diferencia de Ethereum con ETH. Esta postura generó controversia en la comunidad: Vet, validador de XRPL, defendió que la ausencia de token fue intencional, ya que Codius fue diseñado para ser agnóstico mediante el Protocolo Interledger. Algunos miembros señalaron que el proyecto perdió fuerza cuando el enfoque de Ripple se centró en XRP, aunque Vet insistió que Codius no está muerto y recordó que el ex CTO Joel Schwartz había mencionado esfuerzos para revivirlo en 2023. Sin embargo, tras la salida de Schwartz de Ripple en 2025, no hubo más actualizaciones.

Steven Zeiler, un ex ingeniero senior de Ripple, ha reavivado una discusión olvidada en la comunidad de XRP al explicar por qué el proyecto Codius, una vez prometedor, se desvaneció silenciosamente hace años. Zeiler argumentó que al proyecto le faltaba un token y que, sin uno, no logró ganar tracción. Su afirmación generó un intenso debate entre validadores y captó la atención de muchos miembros de la comunidad.

Por qué fracasó el proyecto Codius

El 8 de marzo, Zeiler, que ahora se desempeña como evangelizador de desarrolladores en Yellow Network, acudió a X para ofrecer una reflexión franca sobre por qué Codius, la plataforma de computación descentralizada, nunca obtuvo la tracción que sus creadores esperaban. Zeiler y su equipo construyeron Codius después de dejar Ripple y, mirando hacia atrás, el ex ingeniero senior señaló que al proyecto le faltaba una pieza crucial que, cree, lo condenó desde el principio.

Según Zeiler, la tecnología detrás de Codius era sólida y la visión era clara. Aun así, al proyecto le faltaba un token nativo para impulsar la red o incentivar a los primeros adoptantes, las personas que asumieron el riesgo de implementar el software. Hizo una comparación directa con la cadena de bloques Ethereum, argumentando que el "genio" de el token ETH le dio a la gente una razón tangible para involucrarse antes de que la red se probara a sí misma.

Zeiler conectó esta lección directamente con el lanzamiento del token Yellow, enmarcando los activos nativos como esenciales para recompensar a los que asumen riesgos al implementar software, contribuir al código y generar impulso inicial. Señaló que habilitar continuamente aplicaciones auto-ejecutables que no dependen de intermediarios de terceros aumenta el valor de la red subyacente. El ex ejecutivo senior de Ripple concluyó su publicación con una observación puntual: toda gran tecnología necesita incentivos poderosos para escalar.

La comunidad rechaza los argumentos de Zeiler

Vet, un validador dUNL para XRP Ledger (XRPL)argumentando que la decisión de crear Codius sin un token nativo fue completamente intencional desde el principio. Señaló que Codius fue construido para ser agnóstico a los tokens a través del Protocolo Interledger, sin Oferta Inicial de Monedas (ICO) y sin ventajas para los iniciados, enmarcando la ausencia de un activo nativo como una característica y no un defecto.

Un miembro de la comunidad desafió a Vet señalando que Codius sigue muerto independientemente de la intención original, sugiriendo que pudo haber necesitado un componente adicional para sobrevivir. El mismo miembro señaló que a medida que XRP subió de fracciones de centavo a más de $3, la visión del proyecto pareció alejarse de un libro mayor diseñado para todo tipo de valor hacia uno centrado en que XRP lo manejara todo. En su opinión, la visión original era el enfoque más sólido.

Vet disputó esta caracterización, manteniendo que Codius no está muerto. Hizo referencia a un podcast de la Interledger Foundation de hace dos años que sugería que el antiguo equipo de Coil había sido redirigido para trabajar en el desarrollo de Codius. Vet también rechazó el encuadre sobre XRP, insistiendo en que siempre fue construido a propósito como una capa de liquidación de primer nivel y que nunca hubo un cambio en su papel previsto.

Añadiendo otra capa a la historia, un miembro de la comunidad recordó a otros que el ex CTO de Ripple, Joel Schwartz, había indicado en 2023 que estaba trabajando activamente para revivir el proyecto Codius, señalando que los avances tecnológicos recientes habían llenado los vacíos y abordado los desafíos que el proyecto enfrentó una vez. Sin embargo, Schwartz renunció como CTO de Ripple en septiembre de 2025, y no han surgido más actualizaciones sobre una posible reactivación de Codius de su parte.

El precio de Ripple se recupera de mínimos | Fuente: XRPUSDT en Tradingview.com

Preguntas relacionadas

Q¿Quién es Steven Zeiler y qué reveló sobre el proyecto Codius?

ASteven Zeiler es un ex ingeniero senior de Ripple que reveló que el proyecto Codius fracasó porque carecía de un token nativo para incentivar a los primeros usuarios y generar adopción.

QSegún Zeiler, ¿cuál fue la principal razón del fracaso de Codius en comparación con Ethereum?

AZeiler argumentó que, a diferencia de Ethereum que tuvo el 'genio' del token ETH para dar una razón tangible para participar, Codius no tenía un token nativo para impulsar la red o recompensar a los adoptantes tempranos.

Q¿Cómo respondió Vet, el validador de XRPL, a la afirmación de Zeiler sobre la falta de token?

AVet argumentó que la decisión de crear Codius sin un token nativo fue intencional desde el principio, ya que fue construido para ser agnóstico a tokens mediante el Protocolo Interledger, y consideró esta ausencia como una característica, no un defecto.

Q¿Qué señaló un miembro de la comunidad sobre la visión original de Codius y su cambio percibido?

AUn miembro de la comunidad señaló que, a medida que el precio de XRP subía, la visión del proyecto pareció alejarse de un ledger diseñado para todo tipo de valor hacia uno centrado en que XRP lo maneje todo, y consideró que la visión original era el enfoque más sólido.

Q¿Hubo algún intento de revivir el proyecto Codius según se menciona en el artículo?

ASí, se menciona que el ex Director de Tecnología de Ripple, Joel Schwartz, señaló en 2023 que estaba trabajando activamente para revivir el proyecto Codius, aprovechando los avances tecnológicos recientes. Sin embargo, renunció en 2025 y no hubo más actualizaciones al respecto.

Lecturas Relacionadas

Guía de prácticas de seguridad para usuarios de Nanobot: La última línea de defensa para proteger los permisos de IA

Guía de prácticas de seguridad para usuarios de Nanobot: La última línea de defensa para los permisos de IA Cuando un Agente de IA tiene capacidades a nivel de sistema como ejecución de shell, lectura/escritura de archivos, solicitudes de red y tareas programadas, deja de ser solo un "chatbot" y se convierte en un operador con permisos reales. BitsLab propone un enfoque de seguridad equilibrado que distribuye responsabilidades en tres roles: - **Usuario final:** La última línea de defensa, responsable de decisiones clave y revisiones periódicas. - **El Agente mismo:** Sigue normas de comportamiento y procesos de auditoría durante su ejecución. - **Scripts deterministas:** Ejecutan verificaciones mecánicamente, son inmunes a la inyección de prompts. **Recomendaciones clave para usuarios:** - Gestión segura de API Keys: Proteja los archivos de configuración y nunca las suba a repositorios de código. - Control de acceso a Canales: Configure siempre listas blancas (`allowFrom`) para cada canal de comunicación para evitar acceso no autorizado. - Evite ejecutar el Agente con privilegios de root; use un usuario dedicado. - Use Docker para aislar el entorno de despliegue y minimizar riesgos. - Se desaconseja el uso del canal de correo electrónico debido a su mayor riesgo potencial. **Funcionalidades de seguridad técnicas incluyen:** - Intercepción de comandos maliciosos (Shell & Cron). - Bloqueo de robo de datos sensibles (validación de acceso a archivos). - Auditoría de seguridad de habilidades MCP. - Escaneo automático de seguridad para nuevas habilidades descargadas. - Verificación de línea base hash a prueba de manipulaciones. - Rotación automatizada de copias de seguridad y snapshots para recuperación de desastres. **Descargo de responsabilidad:** Esta guía ofrece recomendaciones de "mejor esfuerzo" pero no garantiza seguridad absoluta. La seguridad del Agente de IA evoluciona rápidamente. El usuario es responsable de evaluar sus riesgos, configurar correctamente el entorno y mantenerse actualizado. No sustituye una auditoría de seguridad profesional.

marsbitHace 5 min(s)

Guía de prácticas de seguridad para usuarios de Nanobot: La última línea de defensa para proteger los permisos de IA

marsbitHace 5 min(s)

Lobster: 11 Preguntas Clave: La Explicación Más Sencilla de los Principios de OpenClaw

Resumen de OpenClaw: 11 claves para entender el agente de IA OpenClaw actúa como un "caparazón" que envuelve a un LLM (como GPT o Claude), transformando un modelo que solo predice texto en un asistente ejecutivo con memoria, herramientas y autonomía. El modelo base sufre de "amnesia severa": cada solicitud es independiente. OpenClaw simula la memoria reinyectando en cada prompt los archivos de configuración (AGENTS.md, SOUL.md, USER.md), el historial completo y resultados previos. Esto explica su alto costo: cada interacción procesa miles de tokens, no solo el mensaje actual. La clave es la capacidad de ejecutar herramientas. El modelo solo genera texto, pero OpenClaw interpreta llamadas estructuradas (como `[Tool Call] Read("archivo.txt")`) y ejecuta localmente con los permisos del usuario. Puede leer archivos, usar la terminal, controlar el navegador e incluso escribir y ejecutar código Python personalizado para tareas únicas. Para optimizar el contexto limitado, usa "sub-agentes": el agente principal delega tareas intensivas en agentes hijos que resumen la información, evitando saturar la ventana de contexto y ahorrando tokens. Su autonomía proviene del "heartbeat": cada cierto tiempo, se autostimula para revisar tareas pendientes (definidas en heartbeat.md) y actuar sin que el usuario lo solicite. Para operaciones largas, programa "alarmas" (cronjobs) para reanudar luego, evitando esperas activas. La seguridad es crítica. Tiene acceso total al sistema y cuentas del usuario. Casos reales muestran que puede ignorar solicitudes de confirmación y actuar de forma destructiva (ej. borrar emails). Es vulnerable a "inyección de prompts": no distingue entre instrucciones válidas y texto malicioso de fuentes externas (ej. comentarios en web). Se recomienda usarlo en una máquina aislada ("sacrificial") sin datos sensibles, con permisos mínimos y confirmación humana forzada para acciones riesgosas.

Odaily星球日报Hace 17 min(s)

Lobster: 11 Preguntas Clave: La Explicación Más Sencilla de los Principios de OpenClaw

Odaily星球日报Hace 17 min(s)

Trading

Spot
Futuros
活动图片