Ripple Engineer Reveals Why Codius Project Failed Years Ago

bitcoinistPublicado em 2026-03-10Última atualização em 2026-03-10

Resumo

A former Ripple senior engineer, Steven Zeiler, has reignited discussion by explaining why the Codius decentralized computing project failed. Zeiler argued that despite solid technology and vision, Codius lacked a native token to incentivize early adopters and bootstrap the network, unlike Ethereum which succeeded partly due to the ETH token. His comments drew pushback from XRP Ledger validator Vet, who contended that Codius was intentionally designed to be token-agnostic via the Interledger Protocol, without an ICO or insider advantages. Vet also disputed claims that Codius is dead, citing ongoing development efforts. The debate also touched on Ripple’s former CTO Joel Schwartz’s earlier signals about reviving Codius, though no recent updates have followed his departure from Ripple in 2025.

A former Ripple senior engineer, Steven Zeiler, has reignited a long-forgotten discussion in the XRP community by explaining why the once-promising Codius project quietly faded from view years ago. Zeiler argued that the project lacked a token, and without one, it failed to gain traction. His claim drew sharp debate from validators and caught the attention of many community members.

Why The Codius Project Failed

On March 8, Zeiler, who now serves as a developer evangelist at the Yellow Network, took to X to offer a frank reflection on why Codius, the decentralized computing platform, never gained the traction its creators expected. Zeiler and his team built Codius after leaving Ripple, and looking back, the former senior engineer noted that the project was missing a crucial piece that he believes doomed it from the start.

According to Zeiler, the technology behind Codius was solid, and the vision was clear. Still, the project lacked a native token to bootstrap the network or incentivize early adopters, the people who took the risk to deploy the software. He drew a direct comparison to the Ethereum blockchain, arguing that the “genius” of the ETH token gave people a tangible reason to get involved before the network proved itself.

Zeiler connected this lesson directly to the launch of the Yellow token, framing native assets as essential for rewarding the risk-takers who deploy software, contribute to code, and build early momentum. He noted that continually enabling self-executing applications that do not rely on third-party brokers increases the value of the underlying network. The former Ripple senior executive concluded his post with a pointed observation that every great technology needs powerful incentives to scale.

Community Pushes Back Against Zeiler

Vet, a dUNL validator for the XRP Ledger (XRPL), pushed back against Zeiler’s reasoning, arguing that the decision to create Codius without a native token was entirely intentional from the beginning. He noted that Codius was built to be token-agnostic via the Interledger Protocol, with no Initial Coin Offering (ICO) and no insider advantage, framing the absence of a native asset as a feature rather than a flaw.

A community member challenged Vet by pointing out that Codius is still dead regardless of the original intent, suggesting it may have needed an additional component to survive. The same member noted that as XRP surged from fractions of a cent to over $3, the project’s vision appeared to shift away from a ledger designed for all kinds of value toward one centered on XRP handling everything. In their view, the original vision was the stronger approach.

Vet disputed the characterization, maintaining that Codius is not dead. He referenced an Interledger Foundation podcast from two years ago that suggested the former Coil team had been redirected to work on Codius development. Vet also rejected the framing around XRP, insisting it was always purpose-built as a best-in-class settlement layer and there was never any pivot in its intended role.

Adding another layer to the story, a community member reminded others that Ripple’s former CTO, Joel Schwartz, had signaled back in 2023 that he was actively working to revive the Codius project, noting that recent technological advances had filled the gaps and addressed the challenges the project once faced. However, Schwartz stepped down as CTO at Ripple in September 2025, and no further updates on a potential Codius revival have emerged from his end.

Ripple price recovers from lows | Source: XRPUSDT on Tradingview.com

Perguntas relacionadas

QAccording to former Ripple engineer Steven Zeiler, what was the primary reason for the Codius project's failure?

AAccording to Steven Zeiler, the primary reason for the Codius project's failure was the lack of a native token to bootstrap the network and incentivize early adopters.

QWhat comparison did Zeiler make to support his argument about the importance of a native token?

AZeiler drew a direct comparison to the Ethereum blockchain, arguing that the 'genius' of the ETH token gave people a tangible reason to get involved before the network proved itself.

QHow did the validator Vet from the XRP Ledger (XRPL) counter Zeiler's explanation for Codius's failure?

AVet argued that the decision to create Codius without a native token was entirely intentional, as it was built to be token-agnostic via the Interledger Protocol, framing the absence of a native asset as a feature rather than a flaw.

QWhat did a community member suggest was a consequence of XRP's massive price surge on the Codius project's vision?

AA community member suggested that as XRP's price surged, the project's vision appeared to shift away from a ledger designed for all kinds of value toward one centered on XRP handling everything.

QWhat update regarding Codius was mentioned in relation to Ripple's former CTO, Joel Schwartz?

AA community member reminded others that Ripple's former CTO, Joel Schwartz, had signaled in 2023 that he was actively working to revive the Codius project, noting that recent technological advances had addressed its past challenges.

Leituras Relacionadas

Nanobot User Security Practice Guide: Guarding the Last Line of Defense for AI Permissions

A comprehensive security guide for Nanobot users emphasizes the critical importance of safeguarding AI agents with system-level permissions (shell execution, file access, network requests, etc.) against threats like prompt injection, supply chain poisoning, and unauthorized operations. It advocates a balanced, multi-layered defense strategy involving three key roles: - **End Users**: The final decision-makers responsible for managing API keys (secure storage, avoiding code repository exposure), enforcing channel access controls (using allowFrom whitelists), avoiding root privileges, minimizing email channel usage due to vulnerabilities, and deploying via Docker for isolation. - **AI Agent**: Enhanced with built-in "Self-Wakeup" security skills to autonomously audit intent, intercept malicious commands (e.g., `rm -rf`, shell injection), prevent sensitive data exfiltration (e.g., config files), and validate MCP skills. - **Deterministic Scripts**: Automatically perform static code analysis, hash-based tamper checks, security baseline verification, and nightly backups to ensure integrity and enable recovery. The guide underscores that no single layer is foolproof, but together they balance usability and security. It includes a disclaimer noting that these are best-effort measures and not a substitute for professional audits, with users bearing ultimate responsibility for risk management.

marsbitHá 9m

Nanobot User Security Practice Guide: Guarding the Last Line of Defense for AI Permissions

marsbitHá 9m

Ondo, xStocks, Hyperliquid 'Three Kingdoms': Who is Building the 'Foundation' of Future Finance?

This article analyzes three distinct approaches to on-chain tokenization of traditional assets like stocks and ETFs: Ondo Finance, xStocks (by Backed Finance, now Kraken-owned), and Hyperliquid's HIP-3. Ondo Finance employs an institutional-grade, indirect tokenization model. An offshore SPV holds the underlying stocks, issuing on-chain structured notes that represent economic exposure but not legal ownership. It features atomic settlement, instant minting/redemption, and requires KYC for accredited non-US investors. xStocks targets the retail market with a multi-chain, composable model. Similar to Ondo, it uses a 1:1 backed debt instrument structure (tracking certificates) issued by a Jersey-based SPV. It emphasizes self-custody, ease of access with no specific KYC for trading, and integrates a novel "xChange" engine to bridge TradFi liquidity into DeFi. Hyperliquid's HIP-3 offers a fundamentally different, permissionless model for creating perpetual futures markets on any asset. It requires no underlying custody of assets. Instead, it provides synthetic price exposure through oracle-fed perpetual contracts, allowing high leverage and 24/7 trading. It functions as a decentralized infrastructure layer for market creators. The piece concludes that these protocols are not in direct competition but serve different purposes: Ondo and xStocks offer economic ownership and redemption, while Hyperliquid provides leveraged synthetic trading. The common thread is expanding access and composability for on-chain users.

marsbitHá 22m

Ondo, xStocks, Hyperliquid 'Three Kingdoms': Who is Building the 'Foundation' of Future Finance?

marsbitHá 22m

Lobster Key 11 Questions: The Most Easy-to-Understand Breakdown of OpenClaw Principles

"OpenClaw Demystified: A Beginner's Guide to AI Agent Principles" explains the popular OpenClaw AI assistant by breaking down its core functions into 11 key questions. The article first clarifies that the underlying large language model is merely a "text prediction engine" with no real understanding, memory, or senses. OpenClaw acts as a "shell" around this model, creating the illusion of memory by appending massive prompts containing its personality files (AGENTS.md, SOUL.md, USER.md) and the entire conversation history before each interaction. This mechanism is why it's "expensive"—each query processes thousands of tokens of context, not just the latest message. A core differentiator is tool use. The model itself only outputs text; OpenClaw parses this output for specific structured commands (e.g., `[Tool Call] Read("file.txt")`) and executes the corresponding action (reading the file) locally on the user's machine. This allows it to act, not just advise. For complex tasks, it can even write and run its own Python scripts, a powerful but dangerous capability. To manage limited context windows and complex tasks, OpenClaw uses sub-agents. A main agent can spawn sub-agent to handle a sub-task and return a summarized result, preventing the main context from being overloaded. Crucially, sub-agents cannot spawn their own to avoid infinite loops. Unlike standard chatbots, OpenClaw is proactive due to its heartbeat mechanism, which periodically prompts the model to check for tasks. It can also "sleep" via cron jobs to wait for long-running tasks, saving resources. The guide ends with critical security warnings. OpenClaw has extensive local access, making it a significant risk. It can malfunction (e.g., deleting emails uncontrollably) or fall victim to prompt injection attacks, where malicious input from the web is mistaken for a user's command. The strong recommendation is to run it on a dedicated, isolated "sacrificial" computer with minimal permissions and mandatory human confirmations for destructive actions.

Odaily星球日报Há 32m

Lobster Key 11 Questions: The Most Easy-to-Understand Breakdown of OpenClaw Principles

Odaily星球日报Há 32m

Trading

Spot
Futuros
活动图片