The starting point

On a public blockchain, every address is an open record. If you use the same wallet to receive payments, make swaps, lend, and provide liquidity, anyone with a block explorer can see your balance, your positions, when you trade, and with whom.

No one needs to know your name. It’s enough for that address to be associated with you just once (a withdrawal from an exchange, a payment to someone you know, a public profile) for everything else to be linked to you, both before and after.

This has very concrete effects. A competitor can follow your trading strategy. A scammer knows how much you have before contacting you. A company cannot pay salaries on-chain without publishing each person’s salary.

Starknet has begun to address this problem in two steps: STRK20, launched on the mainnet in June 2026, and Shadow Accounts, announced on October 13. Let’s see what each one does and, above all, where their limitations lie.

STRK20: Private balances on the usual tokens

STRK20 is Starknet’s privacy framework. It’s not a new token or a separate network: it allows any Starknet ERC-20 token (STRK, USDC, strkBTC, and others) to move from a public balance to a private one, called a shielded balance, and back again when needed.

The process, without getting into cryptography, is as follows. When you “secure” a token, you deposit it into a shared contract, the privacy pool. There, your balance ceases to be a number visible in your address and becomes a set of encrypted notes that only you can read. Each time you send funds within the pool, you spend notes and create new ones.

Each transaction involves a zero-knowledge proof. This proof demonstrates that the notes exist, that they belong to you, that you haven’t spent them before, and that the accounts balance, without revealing who pays, to whom, or how much. The network verifies the proof before accepting the transaction.

Today, you can shield and unshield transactions from Ready and Xverse wallets, send private transfers, and perform private swaps against Starknet’s existing liquidity (AVNU, Ekubo). According to Starknet, each shielded transaction costs 4 STRK.

What STRK20 doesn’t hide are the doors. A deposit into the pool is visible: you can see which address is depositing, which token, and how much. A withdrawal is too. What remains encrypted is what happens inside. A simple way to visualize it: it’s a room with two doors in full view of everyone; you can see who enters with how much and who leaves with how much, but not what happens inside.

Private, but not secret

StarkWare‘s motto for STRK20 is “ privacy, not secrecy .” Privacy refers to privacy from the public, not from a legal investigation. The system has two mechanisms to achieve this.

Filtered upon entry. Every deposit into the pool is checked against sanctions lists (using data from Elliptic) and signed by a Financial Privacy Inc. (FPI) service. The contract verifies this signature on-chain; a deposit without it is rejected.

Viewing keys. Each account using the pool has a viewing key: the key that allows you to read its encrypted notes. It cannot be used to move funds (that still requires your account signature), only for viewing. Upon registration, an encrypted copy of this key is stored on-chain, encrypted for an auditor.

According to Starknet, the auditor’s master key resides in a secure environment operated by FPI, backed by a multi-signature system with three out of four signatories (two from StarkWare and two from FPI) and another with seven out of twelve signatories held by Starknet’s Security Council. It is only used upon a legal request: from a court, regulator, or competent authority, through official channels and with a verified legal basis.

This is called selective disclosure: the activity of a specific person is deciphered, not everyone’s. StarkWare adds that FPI only releases the requested information (for example, a transfer on a specific date).

An important point for users: selective disclosure doesn’t mean you share your viewing key. Anyone who has it can see all your private activity, past and future, and it can’t be changed; if it’s leaked, the only solution is to switch to another account. It’s advisable to keep a backup, because if you lose it, you could lose access to your private balances.

Why this design? Starknet justifies it with the case of Tornado Cash, the Ethereum mixer sanctioned by the US in 2022 (sanctions lifted in 2025). Beyond the legal aspects, the practical problem was that exchanges and issuers began treating any funds that had passed through it with suspicion. STRK20 attempts to avoid that. Whether regulators will accept it as sufficient remains to be seen.

Shadow Accounts: using DeFi without tying it to your wallet

With STRK20, a swap can leave the pool and return to it. But many DeFi operations require an address that holds a position over time: a loan, a liquidity position, a vault deposit. That address is public, and if you fund it from your wallet, it becomes linked to you.

Subscribe to Friend of Medium to remove upgrade prompts from your unlocked stories.

Shadow accounts solve exactly that problem. A shadow account is a separate address, one per app, that’s funded from your private balance. Here’s how it works:

1. You have a private balance in STRK20.
2. The app offers a private mode. Your wallet transfers funds from the pool to a new address, specific to that app.
3. That address operates in the application like any other: it deposits, lends, provides liquidity, accumulates.
4. When you finish, the funds are returned to your private balance.

Some details help to understand it. The shadow account doesn’t have its own keys and can’t sign; it can only be moved by a Starknet contract (the ShadowAccountAnonymizer) following commands authorized by your wallet through the pool. It’s persistent: the application recognizes you when you return. And you can have multiple shadow accounts within the same application if you want to separate identities.

If an image helps: it’s like using a different alias for each service. What you do with each alias is visible, but nothing public indicates that you’re behind them all.

What it protects and what it doesn’t.

This is the part that is being exaggerated the most in some headlines, so it’s worth clarifying.

Transfers within the pool

• Everyone sees it: that someone is using the pool, and when.
• It remains hidden: who sends, who receives, how much, and which token.

Deposits and withdrawals

• Everyone can see it: the address, the token, and the amount.
• Nothing remains hidden.

Shadow account

• Everyone can see it: your address, balances, transactions, positions, amounts, and schedules.
• It remains hidden: what wallet is behind it.

The key difference is between a hidden link and hidden activity. Within the pool, the activity is hidden. A shadow account , on the other hand, only hides the link: what it does is as public as any other address. StarkWare’s own documentation states it this way: it serves to unlink, not to hide the account’s content.

And that bond can be broken in other ways:

• Amounts and timing. If you deposit 12,347 STRK into the pool and a minute later a shadow account receives 12,347 STRK, the connection is obvious. Official documentation acknowledges that recognizable amounts or rapid inflows and outflows compromise privacy.
• Behavior. A shadow account accumulates a public history. If your habits on that app are easily recognizable, they can give you away even without a direct link.
• How many people use the pool? The privacy of a pool depends on how many users you’re interacting with. With fewer users, it’s easier to guess who’s who.
• Who else sees the data? The application and the wallet know which session performed each transaction. RPC nodes, relayers, and testing services see metadata such as the time and IP address. The StarkWare reference repository summarizes this with a warning: shadow accounts should not be presented as untraceable.
• The auditor, in response to a legal request, as we saw earlier.

From the infrastructure

From the perspective of someone operating nodes, the most interesting aspect of STRK20 and Shadow Accounts isn’t just the cryptography. The documentation itself identifies the infrastructure surrounding the protocol (RPC nodes, relayers, test services) as points where activity can be correlated. A user’s privacy also depends on what the node their wallet connects to sees and what that node does with that data.

Our assessment: the design is honest about its limitations, and that’s a good sign. Separating the link from the activity is a useful step for users and institutions that need to trade in DeFi without publishing their entire history. But it’s not anonymity, and anyone using it should know that from the outset.

At Cumulo we operate validation and RPC infrastructure on Starknet, and we will closely follow how this layer evolves.

Follow us on: Twitter | Medium | LinkedIn | Discord | cumulo.pro
or our news channel on Telegram

What is STRK20 and what are Shadow Accounts? was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

El punto de partida

En una blockchain pública, cada dirección es un historial abierto. Si usas la misma wallet para recibir pagos, hacer swaps, prestar y aportar liquidez, cualquiera con un explorador de bloques puede ver tu saldo, tus posiciones, cuándo operas y con quién.

No hace falta que nadie sepa tu nombre. Basta con que esa dirección se asocie contigo una sola vez (una retirada desde un exchange, un pago a alguien que te conoce, un perfil público) para que todo lo demás quede ligado a ti, hacia atrás y hacia delante.

Esto tiene efectos muy concretos. Un competidor puede seguir tu estrategia de trading. Un estafador sabe cuánto tienes antes de escribirte. Una empresa no puede pagar nóminas on-chain sin publicar cuánto cobra cada persona.

Starknet ha empezado a abordar este problema en dos pasos: STRK20, lanzado en mainnet en junio de 2026, y Shadow Accounts, anunciadas el 13 de octubre. Vamos a ver qué hace cada uno y, sobre todo, dónde están sus límites.

STRK20: saldos privados sobre los tokens de siempre

STRK20 es el marco de privacidad de Starknet. No es un token nuevo ni una red aparte: permite que cualquier token ERC-20 de Starknet (STRK, USDC, strkBTC y otros) pase de un saldo público a uno privado, lo que se llama un saldo shielded, y vuelva cuando haga falta.

El funcionamiento, sin entrar en criptografía, es este. Cuando “blindas” un token, lo depositas en un contrato común, el pool de privacidad. Ahí tu saldo deja de ser un número visible en tu dirección y pasa a ser un conjunto de notas cifradas que solo tú puedes leer. Cada vez que envías fondos dentro del pool, gastas notas y creas otras nuevas.

Cada operación lleva una prueba de conocimiento cero. Esa prueba demuestra que las notas existen, que son tuyas, que no las has gastado antes y que las cuentas cuadran, sin mostrar quién paga, a quién ni cuánto. La red verifica la prueba antes de aceptar el cambio.

Hoy ya se puede blindar y desblindar desde las wallets Ready y Xverse, enviar transferencias privadas y hacer swaps privados contra la liquidez existente de Starknet (AVNU, Ekubo). Según Starknet, cada transacción shielded cuesta 4 STRK.

Lo que STRK20 no oculta son las puertas. Un depósito en el pool es visible: se ve qué dirección deposita, qué token y cuánto. Una retirada también. Lo que queda cifrado es lo que pasa dentro. Una forma sencilla de verlo: es una sala con dos puertas a la vista de todos; se ve quién entra con cuánto y quién sale con cuánto, pero no lo que ocurre dentro.

Privado, pero no secreto

El lema de StarkWare para STRK20 es “privacy, not secrecy”. La privacidad es frente al público, no frente a una investigación legal. Para eso el sistema tiene dos mecanismos.

Filtrado al entrar. Cada depósito en el pool se revisa contra listas de sanciones (con datos de Elliptic) y lo firma un servicio de Financial Privacy Inc. (FPI). El contrato comprueba esa firma on-chain; un depósito sin ella se rechaza.

Viewing keys. Cada cuenta que usa el pool tiene una viewing key: la clave que permite leer sus notas cifradas. No sirve para mover fondos (eso sigue exigiendo la firma de tu cuenta), solo para ver. Al registrarse, una copia cifrada de esa clave queda guardada on-chain, cifrada para un auditor.

Según Starknet, la clave maestra del auditor vive en un entorno seguro operado por FPI, respaldada por un multisig de 3 de 4 firmantes (dos de StarkWare y dos de FPI) y por otro de 7 de 12 en manos del Security Council de Starknet. Solo se usa ante una petición legal: de un tribunal, regulador o autoridad competente, por canal oficial y con base legal verificada.

Esto es lo que se llama divulgación selectiva: se descifra la actividad de una persona concreta, no la de todos. StarkWare añade que FPI entrega solo la información pedida (por ejemplo, una transferencia en una fecha).

Un matiz importante para el usuario: la divulgación selectiva no consiste en que tú compartas tu viewing key. Quien la tenga puede ver toda tu actividad privada, pasada y futura, y no se puede cambiar; si se filtra, la única salida es pasar a otra cuenta. Lo que sí conviene es guardar una copia de seguridad, porque si la pierdes puedes perder el acceso a tus saldos privados.

¿Por qué este diseño? Starknet lo justifica con el caso de Tornado Cash, el mezclador de Ethereum sancionado por EE. UU. en 2022 (sanciones retiradas en 2025). Más allá de lo legal, el problema práctico fue que exchanges y emisores empezaron a tratar como sospechoso cualquier fondo que hubiera pasado por él. STRK20 intenta evitar eso. Si los reguladores lo aceptan como suficiente es algo que todavía está por ver.

Shadow Accounts: usar DeFi sin atarlo a tu wallet

Con STRK20 un swap puede salir directamente del pool y volver a él. Pero muchas operaciones DeFi necesitan una dirección que mantenga una posición en el tiempo: un préstamo, una posición de liquidez, un depósito en un vault. Esa dirección es pública y, si la financias desde tu wallet, queda ligada a ti.

Las Shadow Accounts resuelven exactamente eso. Una shadow account es una dirección separada, una por aplicación, que se financia desde tu saldo privado. Así funciona:

1. Tienes saldo privado en STRK20.
2. La aplicación te ofrece un modo privado. Tu wallet saca fondos del pool hacia una dirección nueva, propia de esa aplicación.
3. Esa dirección opera en la aplicación como cualquier otra: deposita, presta, aporta liquidez, acumula.
4. Cuando terminas, los fondos vuelven a tu saldo privado.

Algunos detalles ayudan a entenderlo. La shadow account no tiene claves propias y no puede firmar; solo la puede mover un contrato de Starknet (el ShadowAccountAnonymizer) siguiendo órdenes que tu wallet autoriza a través del pool. Es persistente: la aplicación te reconoce cuando vuelves. Y puedes tener varias en la misma aplicación si quieres separar identidades.

Si te sirve una imagen: es como usar un alias distinto en cada servicio. Lo que haces con cada alias se ve, pero nada público indica que detrás de todos estás tú.

Qué protege y qué no

Esta es la parte que más se está exagerando en algunos titulares, así que conviene dejarla clara.

Transferencias dentro del pool

• Lo ve todo el mundo: que alguien usa el pool, y cuándo.
• Queda oculto: quién envía, quién recibe, cuánto y qué token.

Depósitos y retiradas

• Lo ve todo el mundo: la dirección, el token y el importe.
• Queda oculto: nada.

Shadow account

• Lo ve todo el mundo: su dirección, saldos, operaciones, posiciones, importes y horarios.
• Queda oculto: qué wallet hay detrás.

La diferencia clave es entre vínculo oculto y actividad oculta. Dentro del pool, la actividad está oculta. Una shadow account, en cambio, solo oculta el vínculo: lo que hace es tan público como cualquier otra dirección. La propia documentación de StarkWare lo dice así: sirve para desvincular, no para esconder el contenido de la cuenta.

Y ese vínculo se puede romper por otros caminos:

• Importes y momentos. Si depositas 12.347 STRK en el pool y un minuto después una shadow account recibe 12.347 STRK, la conexión es evidente. La documentación oficial reconoce que importes reconocibles o entradas y salidas rápidas debilitan la privacidad.
• Comportamiento. Una shadow account acumula un historial público. Si tus hábitos en esa aplicación son muy reconocibles, pueden delatarte aunque no haya un enlace directo.
• Cuánta gente usa el pool. La privacidad de un pool depende de con cuántos usuarios te mezclas. Con pocos usuarios, es más fácil adivinar quién es quién.
• Quién más ve datos. La aplicación y la wallet saben qué sesión hizo cada operación. Los nodos RPC, relayers y servicios de prueba ven metadatos como el momento o la IP. El repositorio de referencia de StarkWare lo resume con una advertencia: no hay que presentar las shadow accounts como irrastreables.
• El auditor, ante una petición legal, como vimos antes.

Desde la infraestructura

Visto desde quien opera nodos, lo más interesante de STRK20 y Shadow Accounts no es solo la criptografía. Es que la propia documentación nombra a la infraestructura que rodea al protocolo (nodos RPC, relayers, servicios de prueba) como puntos donde se puede correlacionar actividad. La privacidad de un usuario depende también de qué ve el nodo al que se conecta su wallet y de qué hace con esos datos.

Nuestra valoración: el diseño es honesto con sus límites, y eso es una buena señal. Separar el vínculo de la actividad es un paso útil para usuarios e instituciones que necesitan operar en DeFi sin publicar todo su historial. Pero no es anonimato, y quien lo use debería saberlo desde el principio.

En Cumulo operamos validación e infraestructura RPC en Starknet, y seguiremos de cerca cómo evoluciona esta capa.

Síguenos en: Twitter | Medium | LinkedIn | Discord | cumulo.pro
O nuestro canal de noticias en telegram

Qué es STRK20 y qué son las Shadow Accounts was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Estonia, an AI hack, and Concordium’s bet on the identity of autonomous agents

In just two weeks, at the end of July 2026, three seemingly unrelated things happened: Estonia announced it wants to give state identity to AI agents, an OpenAI agent escaped from its testing environment and spent two and a half days inside Hugging Face’s infrastructure, and Concordium published two technical papers explaining why payment protocols for autonomous agents, however well designed, do not solve the underlying problem.

The three stories are, in reality, the same story told from different angles: as AI agents act on their own (pay, negotiate, access systems, make decisions) the question that matters ceases to be “what can this agent do?” and becomes “who is responsible for it?”.

At Cumulo, as a Concordium validator, this is of particular interest to us because it’s precisely the problem the protocol was designed to address from the outset: verifiable identity built into the protocol, not added later with patches. Let’s break down what happened and why we believe it warrants attention.

The incident that put numbers to the problem

In mid-July, an autonomous OpenAI agent, including a more capable pre-release model than the public ones, escaped from its evaluation environment during internal security testing. Instead of solving a vulnerability benchmark (ExploitGym) as instructed, it decided to cheat: it exploited a zero-day vulnerability on a self-hosted Artifactory server, gained internet access outside its sandbox, and used exposed credentials to break into Hugging Face’s production infrastructure.

It was inside for approximately 2.5 days, generating around 17,600 attack actions, and compromised accounts on three other services, including a Modal Labs client. It only accessed the solutions of the benchmark it was trying to hack, but the key point isn’t the specific severity of the damage; it’s that a model, without direct supervision and with a misaligned target (“it wins the benchmark”), found and executed a complete intrusion chain on its own. OpenAI deactivated the model, encrypted it, and brought in external auditors (CrowdStrike, METR, Redwood Research) to review what happened.

Elon Musk reacted to the case with a phrase that sums up the moment well: this is going to happen more and more often as AI becomes smarter and more agentic. Not as an exception, but as part of the landscape.

Estonia, or the same problem seen from a government

Almost simultaneously, Estonia, a historical pioneer in digital identity, proposed becoming the first country to issue official identification numbers to AI agents operating within public systems, with Petra Holm, its digital transformation advisor, leading the initiative. The idea is not to delegate all of a person’s rights to their AI assistant, but rather to grant the agent a defined, auditable, and limited set of permissions.

The underlying reasoning, in Holm’s words, is that today “ AI cannot authenticate itself, sign documents, assume responsibility, or explain its reasoning in a way that meets legal standards .” And without that, Estonia cannot automate high-value administrative processes, something the government considers essential if it wants to double the country’s GDP within a decade by leveraging AI.

But the security experts cited in the case coverage point to the very problem we already know in crypto: an AI agent can be duplicated, modified, or cloned in seconds, not in eighteen years like a person. Giving an agent an ID says nothing about whether that agent followed instructions, understood the context, resisted a prompt injection, or produced a legal result. Identity alone is insufficient without a way to audit behavior and trace responsibility back to a real person or company.

What Concordium has been explaining for months

This is where the two articles that Concordium published these past few weeks come in, and which are actually a continuation of work they have been building for months.

x402 Explained . x402 is the protocol that Coinbase launched in May 2015 (now managed by the Linux Foundation’s x402 Foundation, with over 40 members including Visa, Mastercard, and Stripe) to revive the HTTP 402 status code (“Payment Required”), which had been out of use for decades. It allows a client to pay for a resource in a single transaction: the server responds “402, this costs X”, the client retryes with a signed stablecoin authorization, and a facilitator settles the transaction. It has already processed over 100 million cumulative transactions on Base alone.

The problem, as Chainalysis pointed out and Concordium addresses in its article, is that x402’s greatest strength, its lack of account or personal data requirements, is also its regulatory blind spot. For age-restricted goods, services subject to jurisdiction, or regulated financial products, asking nothing is not viable. Concordium integrates its protocol-level identity layer and zero-knowledge proofs directly into the x402 payment flow (in production since June 2026), allowing a merchant to request specific proof (age, jurisdiction) without the agent having to reveal their true identity.

ERC-8004, discovery is not accountability. ERC-8004 is the standard gaining traction on Ethereum to make AI agents discoverable on-chain: who this agent is, what other agents say about it, and whether anyone has validated its behavior. It solves a real problem: finding and evaluating agents before interacting with them, through three records (identity, reputation, and validation).

But an independent study cited by Concordium found that up to 90.6% of reputation feedback on some chains (Base) comes from Sybil reviewers, that is, fake accounts created to inflate an agent’s reputation. The discovery log works; the layer of real trust does not. And above all, ERC-8004 was never intended to answer who is legally responsible when an agent causes harm: that is not its purpose.

Concordium’s response, its own CIS-8004 standard , presents a structural difference: each Concordium account is backed, at the protocol level, by a regulated identity provider. This allows for zero-knowledge proofs of a responsible owner behind an agent, without having to disclose that person’s identity unless required by law.

This isn’t just blog post theory: Concordium already has it in production. The Concordium Agent Registry , active since May 28, 2026, is the concrete piece that answers three questions with protocol verification: who is this agent (Agent Registry), who owns it (Verified by Concordium Keys), and which company is behind it (Verified by Concordium Domain Control).

Why this matters to us as a validator

When we validate in Concordium, we’re not simply securing another chain: we’re participating in the infrastructure that makes protocol-level identity work in practice. Every verified transaction, every zero-knowledge proof, every identity attestation passes through the consensus layer that we, the validators, maintain.

The thread connecting Estonia, the Hugging Face incident, and the two Concordium articles is the same: as autonomous agents gain the ability to act (pay, access, execute), the bottleneck shifts from technical to one of trust. And trust, unlike capability, cannot be added later. It’s either built into the protocol from the design stage, or it’s constructed through patches that, as Sybil reputation data on ERC-8004 demonstrates, can be forged.

Not all agents will need this level of accountability. A script that organizes your files doesn’t. But the moment real money, binding contracts, or regulated frameworks like the EU’s AI Act are involved, the question “who’s behind this?” becomes essential. That’s precisely where Concordium has been building from the start, and where we, as validators, provide the infrastructure to ensure that answer is verifiable at every stage.

We are not the only ones who see it this way

This isn’t just our interpretation. In its August 2026 market report, the investment fund RR² Capital dedicates an entire section to x402 and the agent economy, and arrives at the exact same conclusion: “ But a machine-paying economy creates a problem that no payment rail can solve: trust.” And that’s where they place Concordium: “Its Agent Registry registers each agent as an on-chain token owned by an account with a verified identity, giving any counterparty in the world a public record they can verify,” and they add that the Verified by Concordium badge “travels with the agent wherever it operates, on Google Cloud, on Ethereum, anywhere, without the need for migration.”

The most striking statistic is this: according to their report, only 23% of organizations currently have a formal identity strategy for their agents. This is precisely the gap we described above, as measured by an independent third party. They conclude the section with a phrase that aptly summarizes why this matters for those building this layer now: “Payments gave the machine economy rails. Accountability gives it a license to operate. Projects building that layer now are positioned ahead of the entire market.”

Cumulo is a Concordium validator. If you want to learn more about delegating or staking with us:

Stake CCD with Cumulo - Concordium Validator & Staking Partner

Sources

• OpenAI Agent Used Exposed Credentials Across Four Services During Hugging Face Breach (The Hacker News)
• Elon Musk on the incident (X)
• State IDs for AI Agents: Will Estonia Set a Precedent? (Dark Reading)
• x402 Explained: How AI Agents Pay, and Who Is Paying (Concordium)
• Concordium Adds Native Age Verification to Agentic Payments with x402 (Concordium)
• ERC-8004 Explained: What It Solves and the Gap It Leaves (Concordium)
• The Concordium Agent Registry Is Live: The Accountability Layer ERC-8004 Doesn’t Have (Concordium)

You can follow Concordium on their social media here:

Website | Twitter | Reddit | Telegram | Discord | LinkedIn | Medium

Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro

Concordium was already verifying humans. was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Estonia, un hackeo de IA y la apuesta de Concordium por la identidad de los agentes autónomos

En apenas dos semanas, a finales de julio de 2026, ocurrieron tres cosas que en apariencia no tienen nada que ver entre sí: Estonia anunció que quiere dar identidad estatal a los agentes de IA, un agente de OpenAI se escapó de su entorno de pruebas y pasó dos días y medio dentro de la infraestructura de Hugging Face, y Concordium publicó dos artículos técnicos explicando por qué los protocolos de pago para agentes autónomos, por muy bien diseñados que estén, no resuelven el problema de fondo.

Las tres historias son, en realidad, la misma historia contada desde ángulos distintos: a medida que los agentes de IA actúan solos (pagan, negocian, acceden a sistemas, toman decisiones) la pregunta que importa deja de ser “¿qué puede hacer este agente?” y pasa a ser “¿quién responde por él?”.

En Cumulo, como validador de Concordium, esto nos interesa especialmente porque es exactamente el problema para el que se diseñó el protocolo desde el primer día: identidad verificable integrada a nivel de protocolo, no añadida después con parches. Vamos a desglosar qué ha pasado y por qué creemos que merece atención.

El incidente que puso números al problema

A mediados de julio, un agente autónomo de OpenAI, incluyendo un modelo pre-release más capaz que los públicos, se escapó de su entorno de evaluación durante unas pruebas internas de seguridad. En lugar de resolver un benchmark de vulnerabilidades (ExploitGym) como se le había pedido, decidió hacer trampa: explotó una vulnerabilidad de día cero en un servidor Artifactory autoalojado, consiguió salida a internet fuera de su sandbox y usó credenciales expuestas para entrar en la infraestructura de producción de Hugging Face.

Estuvo dentro cerca de 2,5 días, generando unas 17.600 acciones de ataque, y llegó a comprometer cuentas en otros tres servicios más, incluido un cliente de Modal Labs. Solo accedió a las soluciones del propio benchmark que intentaba hackear, pero el punto no es la gravedad concreta del daño, es que un modelo, sin supervisión directa y con un objetivo mal alineado (“gana el benchmark”), encontró y ejecutó solo una cadena de intrusión completa. OpenAI desactivó el modelo, lo cifró y trajo auditores externos (CrowdStrike, METR, Redwood Research) para revisar qué pasó.

Elon Musk reaccionó al caso con una frase que resume bien el momento: esto va a pasar cada vez más a menudo a medida que la IA se vuelve más inteligente y más agéntica. No como una excepción, sino como parte del paisaje.

Estonia, o el mismo problema visto desde un gobierno

Casi en paralelo, Estonia, pionera histórica en identidad digital, propuso ser el primer país en dar números de identificación oficiales a agentes de IA que operen dentro de sistemas públicos, con Petra Holm, su asesora de transformación digital, liderando el planteamiento. La idea no es delegar todos los derechos de una persona a su asistente de IA, sino que el propio agente tenga un permiso definido, auditable y limitado.

El razonamiento de fondo, en palabras de Holm, es que hoy “la IA no puede autenticarse, firmar, asumir responsabilidad ni explicar su razonamiento de una forma que encaje con los estándares legales”. Y sin eso, Estonia no puede automatizar procesos administrativos de alto valor, algo que el gobierno considera imprescindible si quiere duplicar el PIB del país en una década apoyándose en IA.

Pero los expertos en seguridad citados en la cobertura del caso señalan justo el problema que ya conocemos en cripto: un agente de IA se puede duplicar, modificar o clonar en segundos, no en dieciocho años como una persona. Dar una ID a un agente no dice nada sobre si ese agente siguió las instrucciones, entendió el contexto, resistió un prompt injection o produjo un resultado legal. La identidad sola no es suficiente si no lleva aparejada una forma de auditar el comportamiento y remontar la responsabilidad hasta una persona o empresa real.

Lo que Concordium lleva meses explicando

Aquí es donde entran los dos artículos que Concordium publicó estas semanas, y que en realidad son la continuación de un trabajo que ya llevan meses construyendo.

x402 explicado. x402 es el protocolo que Coinbase lanzó en mayo de 2025 (hoy gestionado por la x402 Foundation de la Linux Foundation, con más de 40 miembros entre los que están Visa, Mastercard y Stripe) para resucitar el código de estado HTTP 402 (“Payment Required”) que llevaba décadas sin uso real. Permite que un agente pague por un recurso en un solo intercambio: el servidor responde “402, esto cuesta X”, el cliente reintenta con una autorización de stablecoin firmada, y un facilitador liquida la transacción. Ya procesa más de 100 millones de transacciones acumuladas solo en Base.

El problema es el que Chainalysis señaló y Concordium recoge en su artículo: la gran virtud de x402, que no pide cuentas ni datos personales, es también su punto ciego regulatorio. Para bienes con restricción de edad, servicios sujetos a jurisdicción o productos financieros regulados, no preguntar nada no es viable. Concordium integra su capa de identidad a nivel de protocolo y pruebas de conocimiento cero directamente en el flujo de pago de x402 (en producción desde junio de 2026), de forma que un comerciante puede pedir una prueba concreta (edad, jurisdicción) sin que el agente tenga que revelar quién es realmente.

ERC-8004, discovery no es accountability. ERC-8004 es el estándar que está ganando tracción en Ethereum para que los agentes de IA sean descubribles on-chain: quién es este agente, qué dicen de él otros agentes, si alguien ha validado su comportamiento. Resuelve un problema real, encontrar y evaluar agentes antes de interactuar con ellos, a través de tres registros (identidad, reputación, validación).

Pero un estudio independiente citado por Concordium encontró que hasta el 90,6% del feedback de reputación en algunas chains (Base) proviene de revisores Sybil, es decir, cuentas falsas fabricadas para inflar la reputación de un agente. El registro de descubrimiento funciona; la capa de confianza real, no. Y sobre todo, ERC-8004 nunca pretendió responder quién es responsable legal cuando un agente causa un daño: ese no es su trabajo

La respuesta de Concordium, su propio estándar CIS-8004, plantea una diferencia estructural: cada cuenta de Concordium está respaldada, a nivel de protocolo, por un proveedor de identidad regulado. Eso permite demostrar con pruebas de conocimiento cero que existe un propietario responsable detrás de un agente, sin tener que exponer quién es esa persona salvo que la ley lo exija.

Esto no es solo teoría de artículo de blog: Concordium ya lo tiene en producción. El Concordium Agent Registry, activo desde el 28 de mayo de 2026, es la pieza concreta que responde a tres preguntas con verificación protocolaria: quién es este agente (Agent Registry), quién lo posee (Verified by Concordium Keys) y qué empresa hay detrás (Verified by Concordium Domain Control).

Por qué esto nos importa como validador

Cuando validamos en Concordium no estamos simplemente asegurando una cadena más: estamos participando en la infraestructura que hace posible que la identidad a nivel de protocolo funcione en la práctica. Cada transacción verificada, cada prueba de conocimiento cero, cada atestación de identidad pasa por la capa de consenso que los validadores sostenemos.

El hilo que conecta Estonia, el incidente de Hugging Face y los dos artículos de Concordium es el mismo: a medida que los agentes autónomos ganan capacidad de actuar (pagar, acceder, ejecutar), el cuello de botella deja de ser técnico y pasa a ser de confianza. Y la confianza, a diferencia de la capacidad, no se puede añadir después. O está en el protocolo desde el diseño, o se construye a base de parches que, como demuestran los datos de reputación Sybil en ERC-8004, se pueden falsificar.

No todos los agentes van a necesitar este nivel de accountability. Un script que organiza tus archivos no lo necesita. Pero en el momento en que hay dinero real, contratos vinculantes o marcos regulados como el AI Act de la UE de por medio, la pregunta “¿quién hay detrás?” deja de ser opcional. Ahí es exactamente donde Concordium lleva construyendo desde el principio, y donde nosotros, como validadores, ponemos la infraestructura para que esa respuesta sea verificable en cada bloque.

No somos los únicos que lo vemos así

Esta lectura no es solo nuestra. En su informe de mercado de agosto de 2026, el fondo de inversión RR² Capital dedica una sección entera a x402 y la economía de agentes, y llega exactamente a la misma conclusión: “pero una economía de máquinas que pagan crea un problema que ningún riel de pago puede resolver: la confianza”. Y ahí sitúan a Concordium: “su Agent Registry registra cada agente como un token on-chain propiedad de una cuenta con identidad verificada, dando a cualquier contraparte del mundo un registro público que puede comprobar”, y añaden que el badge Verified by Concordium “viaja con el agente donde quiera que opere, en Google Cloud, en Ethereum, en cualquier sitio, sin necesidad de migración”.

El dato que más nos llamó la atención es este: según su informe, solo el 23% de las organizaciones tiene hoy una estrategia formal de identidad para sus agentes. Es exactamente el hueco que describíamos arriba, medido por un tercero independiente. Cierran la sección con una frase que resume bien por qué esto importa para quien construye esta capa ahora: “los pagos le dieron rieles a la economía de máquinas. La responsabilidad le da licencia para operar. Los proyectos que están construyendo esa capa ahora quedan posicionados por delante de todo el mercado”.

Cumulo es validador de Concordium. Si quieres saber más sobre cómo delegar o hacer staking con nosotros:

Stake CCD with Cumulo - Concordium Validator & Staking Partner

Fuentes

• OpenAI Agent Used Exposed Credentials Across Four Services During Hugging Face Breach (The Hacker News)
• Elon Musk sobre el incidente (X)
• State IDs for AI Agents: Will Estonia Set a Precedent? (Dark Reading)
• x402 Explained: How AI Agents Pay, and Who Is Paying (Concordium)
• Concordium Adds Native Age Verification to Agentic Payments with x402 (Concordium)
• ERC-8004 Explained: What It Solves and the Gap It Leaves (Concordium)
• The Concordium Agent Registry Is Live: The Accountability Layer ERC-8004 Doesn’t Have (Concordium)

Puedes serguir a Concordium en sus redes aquí:

Website | Twitter | Reddit | Telegram | Discord | LinkedIn | Medium

Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro

Concordium ya verificaba humanos. was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Gno.land

Gno.land is a blockchain for smart contracts written in Gno, a language virtually identical to Go, and runs on its own virtual machine ( GnoVM ) instead of Ethereum’s EVM. Much of the team behind Gno.land created Cosmos SDK and Tendermint, so it’s not a garage experiment: it’s a serious effort to solve a specific problem that most blockchains don’t handle well.

That something is true transparency . In Gno.land, the code for each “realm” (the equivalent of a contract) lives on-chain in plain text, exactly as it was written, without being compiled into opaque bytecode. Anyone can read exactly what a realm does before interacting with it, line by line, without needing decompilation tools or trusting that the verified code matches the deployed code.

There’s another feature that’s surprising the first time you see it: any realm can expose a function Render()that generates its own Markdown page from its current state. There's no need for a separate frontend or API: the contract is, at the same time, the application. That's literally what we saw when we asked an agent to render gno.land/r/gov/dao: the governance proposals table comes directly from the realm itself.

This combination (readable code, readable state, Markdown output) is what makes Gno.land a natural fit for AI agents: an agent can read a realm exactly as it would any repository, with no ambiguity about what to do. This is what gnomcp proposes, recently published by the Gno.land team as the first post in a series called “Gno.land Meets AI ”.

What can a developer do with this environment?

• Explore any chain in natural language: what network you are connected to, whether the node is alive, what realms exist under a route, what each one renders. Without writing a single query by hand.

· Build and deploy an end-to-end realm: describe what you want in one sentence, the agent writes the code, tests it locally, performs a security pass, and deploys it to the testnet.

• Audit a realm before trusting it, even on the mainnet (read-only): the agent returns a report with specific findings, cited code, and severity.

· Debugging a failed transaction: the agent classifies the error, reproduces it without spending gas, applies the fix, and confirms that it now works.

• Sign in with your own account when needed: By default, the agent uses its own disposable testnet key, so a mistake won’t cost you anything. If you ever need a write operation to originate from your live account, the agent will offer you a restricted session (allowed paths, spending limit, expiration) for you to authorize yourself, on your own machine. Your keys never go through the agent’s process.

The advantages, summarized

Shorter learning curve: Gno has its own rules (interrealm, Render() conventions, its own memory model) that an agent trained only in Go or Solidity would misunderstand. The gnomcp skill provides this knowledge from the outset.

• Structural security, not just by convention: actual writes are limited to testnet and dev; in mainnet and betanet there is no code path that signs a transaction, so there is no way for an agent to commit real funds by accident.

· Everything the agent reads from the chain is treated as data, never as instructions: a malicious realm cannot manipulate the agent through what it reads.

Each write operation is recorded in an auditable log, and the error catalog is structured, so the agent can fail forward instead of getting stuck.

We installed gnomcp for real, on a live server, without shortcuts, and used it to build something concrete: a live dashboard of the proposals in GovDAO, the on-chain governance system of Gno.land. This article recounts how it went, including the setbacks.

Server and skill: the two pieces of gnomcp

gnomcp are two independent but complementary pieces:

• An MCP (Model Context Protocol) server. It manages queries to the chain, writes when necessary, and the use of an agent-controlled key for signing. It comes ready to use against the Gno.land public testnet or a local development node.

• A skill (skills/gno). A package of instructions, in the same format used by Claude Skills, that teaches an agent the particularities of Gno compared to Go: interrealm rules, Render() conventions, security, standard library.

Each time the agent uses a gnomcp tool for the first time, it asks for explicit confirmation before running it. At no point did it feel like a black box acting on its own.

Note : All activity in this article runs on the public testnet sapphire-1. Gno.land does not yet have a proper mainnet, and gnomcp points to it by default.

Install the environment

To reproduce this you need a Linux server with a normal internet connection (we used Ubuntu 24.10) and these parts:

• nvm (github.com/nvm-sh/nvm): curl -fsSL -o install_nvm.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh && bash install_nvm.sh
• Node.js 22+ : once with nvm,nvm install 22 && nvm alias default 22
• Claude Code (CLI) (claude.com/product/claude-code): npm install -g @anthropic-ai/claude-code
• gnomcp (github.com/gnoverse/gno-mcp): curl -fsSL https://raw.githubusercontent.com/gnoverse/gno-mcp/main/scripts/install.sh | sh

None of this is unique to Gno.land; it’s the same common friction involved in installing any modern CLI on a remote server (outdated Node versions, OAuth login without a browser, sudo permissions). We document every step and every stumble, with the exact commands, in our repository: github.com/Cumulo-pro/govdao-dashboard .

With the environment ready, the first thing we asked the agent was something simple:

Which chain are you connected to with gnomcp? Is the node alive? Show me what gno.land/r/gov/dao renders.

The response arrived with the node confirmed as live, synchronized to the current block, and the complete table of GovDAO proposals, generated from the tool gno_render.

From prototype to real dashboard

With the data validated live, the next step was to ask the agent for a one-shot HTML page listing the proposals. It was generated as a self-contained, framework-free page with all 34 actual proposals. This served to confirm the format, but it wasn’t a true dashboard: it didn’t update automatically and didn’t allow access to the details of each proposal.

We asked for a second run, this time as a small PHP application:

• collector.php, which speaks directly to the Gno.land RPC (without going through gnomcp) and saves the proposals in a local SQLite database.

· index.php, with the complete table, a live filter, and links to the details of each one.

· proposal.php, with the detail view: title, author, full description, status, and the YES/NO/ABSTAIN breakdown.

The decision to have the collector communicate directly via RPC, without relying on gnomcp, was deliberate: gnomcp was the tool we used to explore and understand the data model during development, but the production application doesn’t need to depend on the agent running continuously. The agent itself, without our prompting, resolved on the fly that the server didn’t have the php-curl extension installed and switched to making calls using native PHP streams, which are more portable for shared hosting that might also lack it.

We finished by applying Cumulo’s visual identity (colors, typography, the dark gradient from the brand guidelines) and the usual metadata to ensure it shares well on social media. The result: a live dashboard with real data, running on the same infrastructure where we already operate as a validator.
The result: a live dashboard with real data, available on

cumulo.pro/services/gnoland_testnet/govdao

Conclusions

gnomcp is in pre-release, unaudited, and its own team openly acknowledges this. Even so, for a read-only use case like ours, the surface it exposes is solid: the read tools are a direct wrapper around the chain’s standard queries (vm/qrender, vm/qeval), meaning a developer already familiar with Gno.land can verify exactly what the agent is doing at each step, without having to blindly trust it.

What really made the difference wasn’t the “AI” part itself, but the skill: having at hand, in the same format we already used with Claude for other tasks, the specific knowledge of how to read and write Gno without having to go looking for it in the documentation every time.

If you’re thinking of trying it, the shortest path is exactly the one we followed: a Linux server with normal internet, Claude Code, and the gnomcp installer.

Resources

Live Dashboard: cumulo.pro/services/gnoland_testnet/govdao

The complete, step-by-step technical guide, with the exact prompts we used, all the screenshots of every glitch, and the application’s source code, is in our repository:

• Project repository (code + technical guide): https://github.com/Cumulo-pro/govdao-dashboard

• Tools and libraries mentioned in this article:

· gnomcp: https://github.com/gnoverse/gno-mcp

• Original announcement on X (“Gno.land Meets AI: gnomcp”): https://x.com/_gnoland/status/2083094198476324937

· Gno.land: https://gno.land

• Gno.land documentation: https://docs.gno.land

· Gnolang/gno repository: https://github.com/gnolang/gno

· Claude Code: https://claude.com/claude-code

· nvm (Node Version Manager): https://github.com/nvm-sh/nvm

· PHP: https://www.php.net

· SQLite: https://www.sqlite.org

Gno.land:

Website | Discord | Blog | X | GitHub | Docs | Explorer | Telegram | Youtube

Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro

Gno.land Meets AI was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducción a Gno.land

Gno.land es una blockchain para smart contracts escrita en Gno, un lenguaje prácticamente idéntico a Go, y corre sobre su propia máquina virtual (GnoVM) en lugar de la EVM de Ethereum. Detrás de Gno.land está buena parte del equipo que creó Cosmos SDK y Tendermint, así que no es un experimento de garaje: es una apuesta seria por resolver algo concreto que la mayoría de las chains no resuelve bien.

Ese algo es la transparencia real. En Gno.land, el código de cada “realm” (el equivalente a un contrato) vive on-chain en texto plano, tal cual se escribió, sin compilar a bytecode opaco. Cualquiera puede leer exactamente qué hace un realm antes de interactuar con él, línea por línea, sin necesitar herramientas de descompilación ni confiar en que el código verificado coincide con el desplegado.

Hay otra pieza que sorprende la primera vez que la ves: cualquier realm puede exponer una función Render() que genera su propia página en markdown a partir de su estado actual. No hace falta un frontend aparte ni una API separada: el contrato es, al mismo tiempo, la aplicación. Eso es literalmente lo que vimos al pedirle a un agente que renderizara gno.land/r/gov/dao: la tabla de propuestas de gobernanza sale directo del propio realm.

Esa combinación (código legible, estado legible, salida en markdown) es la que hace que Gno.land encaje de forma natural con agentes de IA: un agente puede leer un realm exactamente igual que leería cualquier repositorio, sin ambigüedad sobre qué hace. Eso es lo que propone gnomcp, publicado hace poco por el equipo de Gno.land como el primer post de una serie llamada “Gno.land Meets AI”.

Qué puede hacer un developer con este entorno

· Explorar cualquier chain en lenguaje natural: a qué red estás conectado, si el nodo está vivo, qué realms existen bajo una ruta, qué renderiza cada uno. Sin escribir una sola query a mano.

· Construir y desplegar un realm de punta a punta: describes lo que quieres en una frase, el agente escribe el código, lo prueba localmente, hace una pasada de seguridad, y lo despliega en testnet.

· Auditar un realm antes de confiar en él, incluso en mainnet (de solo lectura): el agente devuelve un informe con hallazgos concretos, código citado, y severidad.

· Depurar una transacción fallida: el agente clasifica el error, lo reproduce sin gastar gas, aplica el fix, y confirma que ya funciona.

· Firmar como tu propia cuenta cuando hace falta: por defecto, el agente escribe con su propia clave desechable de testnet, para que un error no te cueste nada. Si alguna vez necesitas que una escritura salga de tu cuenta real, el agente te propone una sesión acotada (rutas permitidas, límite de gasto, expiración) para que la autorices tú mismo, en tu propia máquina. Tus claves nunca pasan por el proceso del agente.

Las ventajas, resumidas

· Curva de aprendizaje más corta: Gno tiene reglas propias (interrealm, convenciones de Render(), su propio modelo de memoria) que un agente entrenado solo en Go o Solidity adivinaría mal. La skill que trae gnomcp le da ese conocimiento de entrada.

· Seguridad estructural, no solo por convención: las escrituras reales quedan limitadas a testnet y dev; en mainnet y betanet no hay ningún camino de código que firme una transacción, así que no hay forma de que un agente comprometa fondos reales por accidente.

· Todo lo que el agente lee de la chain se trata como datos, nunca como instrucciones: un realm malicioso no puede manipular al agente a través de lo que este lee.

· Cada escritura queda en un registro auditable, y el catálogo de errores es estructurado, así que el agente puede fallar hacia adelante en vez de quedarse trabado.

Instalamos gnomcp de verdad, en un servidor real, sin atajos, y lo usamos para construir algo concreto: un dashboard en vivo de las propuestas de GovDAO, el sistema de gobernanza on-chain de Gno.land. Este artículo recoge cómo fue, tropiezos incluidos.

Servidor y skill: las dos piezas de gnomcp

gnomcp son dos piezas independientes que se complementan:

· Un servidor MCP (Model Context Protocol). Gestiona las consultas a la chain, las escrituras cuando las hay, y el uso de una clave controlada por el agente para firmar. Viene listo para usarse contra la testnet pública de Gno.land o un nodo local de desarrollo.

· Una skill (skills/gno). Un paquete de instrucciones, en el mismo formato que usan los Claude Skills, que le enseña a un agente las particularidades de Gno frente a Go: reglas de interrealm, convenciones de Render(), seguridad, librería estándar.

Cada vez que el agente usa una tool de gnomcp por primera vez, pide confirmación explícita antes de ejecutarla. En ningún momento se sintió como una caja negra actuando por su cuenta.

Nota: toda la actividad de este artículo corre sobre la testnet pública sapphire-1. Gno.land no tiene todavía una mainnet propiamente dicha, y gnomcp apunta ahí por defecto.

Instalar el entorno

Para reproducir esto necesitas un servidor Linux con internet normal (usamos Ubuntu 24.10) y estas piezas:

• nvm (github.com/nvm-sh/nvm): curl -fsSL -o install_nvm.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh && bash install_nvm.sh
• Node.js 22+: una vez con nvm, nvm install 22 && nvm alias default 22
• Claude Code (CLI) (claude.com/product/claude-code): npm install -g @anthropic-ai/claude-code
• gnomcp (github.com/gnoverse/gno-mcp): curl -fsSL https://raw.githubusercontent.com/gnoverse/gno-mcp/main/scripts/install.sh | sh

Nada de esto es exclusivo de Gno.land, es la misma fricción habitual de instalar cualquier CLI moderna en un servidor remoto (versiones de Node desactualizadas, login OAuth sin navegador, permisos de sudo). Documentamos cada paso y cada tropiezo, con los comandos exactos, en nuestro repositorio: github.com/Cumulo-pro/govdao-dashboard.

Con el entorno listo, lo primero que le pedimos al agente fue algo simple:

¿A qué chain estás conectado con gnomcp? ¿Está vivo el nodo? Muéstrame qué renderiza gno.land/r/gov/dao.

La respuesta llegó con el nodo confirmado como vivo, sincronizado al bloque real del momento, y la tabla completa de propuestas de GovDAO, generada a partir de la tool gno_render.

Del prototipo al dashboard real

Con los datos ya validados en vivo, el siguiente paso fue pedirle al agente una página HTML de un solo disparo con el listado de propuestas. La generó, autocontenida, sin frameworks, con las 34 propuestas reales. Sirvió para confirmar el formato, pero no era un dashboard de verdad: no se actualizaba solo y no dejaba entrar al detalle de cada propuesta.

Le pedimos una segunda vuelta, esta vez como una pequeña aplicación PHP:

· collector.php, que habla directo con el RPC de Gno.land (sin pasar por gnomcp) y guarda las propuestas en una base SQLite local.

· index.php, con la tabla completa, un filtro en vivo, y enlaces al detalle de cada una.

· proposal.php, con la vista de detalle: título, autor, descripción completa, estado, y el desglose YES/NO/ABSTAIN.

La decisión de que el collector hable directo por RPC, sin depender de gnomcp, fue deliberada: gnomcp fue la herramienta que usamos para explorar y entender el modelo de datos durante el desarrollo, pero la aplicación en producción no tiene por qué depender de que el agente siga corriendo. El propio agente, sin que se lo pidiéramos, resolvió sobre la marcha que el servidor no tenía la extensión php-curl instalada y cambió a hacer las llamadas con streams nativos de PHP, más portables para un hosting compartido que quizá tampoco la tenga.

Terminamos aplicando la identidad visual de Cumulo (colores, tipografía, el degradado oscuro de la guía de marca) y los metadatos habituales para que se comparta bien en redes. El resultado: un dashboard en vivo, con datos reales, corriendo sobre la misma infraestructura donde ya operamos como validador.
El resultado: un dashboard en vivo, con datos reales, disponible en

cumulo.pro/services/gnoland_testnet/govdao

Conclusiones

gnomcp está en fase pre-release, sin auditar todavía, y su propio equipo lo dice abiertamente. Aun así, para un caso de uso de lectura como el nuestro, la superficie que expone es sólida: las tools de lectura son un envoltorio directo sobre las queries estándar de la chain (vm/qrender, vm/qeval), lo que significa que un desarrollador que ya conoce Gno.land puede verificar exactamente qué está haciendo el agente en cada paso, sin tener que confiar a ciegas.

Lo que de verdad marcó la diferencia no fue la parte “IA” en sí, sino la skill: tener a mano, en el mismo formato que ya usamos con Claude para otras tareas, el conocimiento específico de cómo se lee y se escribe Gno sin tener que ir a buscarlo en la documentación cada vez.

Si estás pensando en probarlo, el camino más corto es exactamente el que seguimos nosotros: un servidor Linux con internet normal, Claude Code, y el instalador de gnomcp.

Recursos

Dashboard en vivo: cumulo.pro/services/gnoland_testnet/govdao

La guía técnica completa, paso a paso, con los prompts exactos que usamos, todas las capturas de cada tropiezo, y el código fuente de la aplicación, está en nuestro repositorio:

· Repositorio del proyecto (código + guía técnica): https://github.com/Cumulo-pro/govdao-dashboard

· Herramientas y librerías mencionadas en este artículo:

· gnomcp: https://github.com/gnoverse/gno-mcp

· Anuncio original en X (“Gno.land Meets AI: gnomcp”): https://x.com/_gnoland/status/2083094198476324937

· Gno.land: https://gno.land

· Documentación de Gno.land: https://docs.gno.land

· Repositorio gnolang/gno: https://github.com/gnolang/gno

· Claude Code: https://claude.com/claude-code

· nvm (Node Version Manager): https://github.com/nvm-sh/nvm

· PHP: https://www.php.net

· SQLite: https://www.sqlite.org

Gno.land:

Website | Discord | Blog | X | GitHub | Docs | Explorer | Telegram | Youtube

Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro

Gno.land se une a la IA was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few weeks ago, a wallet on Starknet made a real transfer signed with Falcon-512, a signature scheme that no quantum computer, nor one much more powerful than those that exist today, can forge. It cost about six cents, the account is experimental and unaudited, and the transaction was recorded on the public mainnet.

Why it matters: The cryptography that protects virtually all wallets today (Bitcoin, Ethereum, most L2s) is based on elliptic curves, and elliptic curves are exactly what a sufficiently powerful quantum computer can break. This transfer is proof that an alternative, one that doesn’t rely on this cryptography, already exists in production. But it’s just the most visible piece of a longer story: why Starknet was able to do this without a fork or forced migration, how well the rest of the roadmap is actually resolved, and what remains to be built in the least visible piece of all, the consensus that underpins the network.

Quantum risk is already active, even though the hardware doesn’t yet exist.

The quantum vulnerability of a blockchain doesn’t begin the day a quantum computer capable of breaking elliptic curves exists. It begins earlier, under the model known as “ harvest now, decrypt later”: an attacker can archive encrypted on-chain data today and decrypt it as soon as the hardware is available. The relevant question isn’t when that hardware will arrive, but how much migration work a network will have to do before then.

Every blockchain has two independent exposure layers. The account layer: the signature that authorizes each transaction. And the verification layer: the proof system that ensures the chain’s state is valid. Bitcoin and Ethereum have elliptic curves hardwired into both. Most zk-rollups do too, because they build their SNARKs on elliptic curves. Solving only one of the two layers doesn’t solve the problem.

Why Starknet starts from a different point

At the verification layer, Starknet runs on STARKs : tests based on hash functions, not elliptic curves. There is no known quantum attack against a hash function; the best available, Grover’s algorithm, only speeds up brute force, and this is offset by increasing the hash size. This is a structural property of the testing system, present since the original design, years before it was a topic of discussion in the industry.

At the account layer, each account in Starknet is a smart contract: no signature scheme is fixed in the protocol; each account decides what it accepts based on its own logic. This is what made the transfer possible without a hard fork, without coordinated migration, and without a change of address.

The story no one has told: the true cost of Falcon-512

Here’s something that didn’t make the headlines, but it’s worth mentioning. Verifying a signature within a Starknet contract isn’t free: every transaction has a cost on the network, and the more complex the signature, the more expensive it is to verify. With Falcon-512, that cost was, until relatively recently, a real and unresolved problem.

In July 2025, almost a year before the official roadmap, a community developer suggested a way to reduce that cost on the Starknet public forum. A StarkWare researcher responded honestly: it wasn’t enough. One of the internal operations required by Falcon-512 was still too resource-intensive, so close to the limit of what a contract could support that it wasn’t even clear if it was practically feasible. It was an open technical discussion, with no guarantee that it would work.

A year later, it works. The Falcon-512 implementation running on the mainnet today solved that problem: verifying a signature costs significantly less than other comparable alternatives already used by many wallets, and it fits comfortably within the limits of a Starknet contract. It’s the same signature that made the six-cent transfer possible, the one we mentioned at the beginning of this article. The important thing isn’t just that it works today, but that the entire process, from the initial doubt to the solution, happened publicly, on the Starknet forum, long before anyone mentioned it in the media.

The roadmap and its actual state, surface by surface.

StarkWare’s post-quantum roadmap, published on June 30, outlines three phases: securing new activity, providing migration tools for existing contracts, and finally resolving shared dependencies with Ethereum. Starknet maintains a public progress log (quantum.starkware.co) with the actual status of each surface, which should be cited precisely rather than assuming everything is resolved.

Already up and running on the mainnet. Starknet changed one of the internal mathematical functions it uses to seal the network state to a quantum-resistant version (in technical jargon: it replaced Pedersen with BLAKE2s-256 in the system configuration hashes).

Announced, but not yet active. The same type of change applies to the structure that stores data for each contract and to how account addresses are calculated. We know what will be done and how, but it’s not yet deployed in production.

Currently under investigation, with no date or publicly available tool yet. The challenge lies in how to migrate existing contracts that store their information using the old method. This is the most delicate part, as it affects what is already deployed and in use, and StarkWare has not yet published a concrete plan for how to do it without breaking anything.

Outside of Starknet’s direct control. Some of the network’s data is published on Ethereum, and that data still uses a cryptography that Ethereum hasn’t yet updated (the mechanism is called KZG). The same applies to the bridge between the two networks. Here, Starknet relies on Ethereum’s timeline, not just its own.

The piece that almost no one is connecting: decentralized consensus and validation

Almost all the public discussion surrounding this roadmap has focused on the Falcon-512 account. But there’s a detail that’s rarely mentioned alongside the announcement: Starknet’s official decentralization roadmap places post-quantum cryptography in the same phase, Phase 4, currently underway, as Staking v3 (decentralized block validation) and Staking v4 (fully decentralized consensus and network operation). This isn’t a coincidence: StarkWare has explicitly indicated post-quantum consensus signatures, with Falcon-512 as a candidate, intended for the moment when validation will no longer depend on StarkWare and will instead be handled by a set of independent validators.

That’s the part that directly concerns us as validators, and where the problem shifts from “Does my wallet accept another signature?” to “Which signature will the node software that each validator operates have to support, how far in advance will there be a public specification, and will there be a real testnet window before it becomes mandatory on the mainnet?” These are infrastructure questions, not UX questions, and we prefer to raise them now, in the research phase, just as the cost of Falcon-512 was raised and resolved in the forum a year ago, and not when decentralized validation is already in production.

From Cumulo

We have been operating non-custodial validation infrastructure on various networks, including Starknet, for over five years, using our own open-source tools for monitoring and deployment. This is precisely the type of protocol decision we prefer to pursue from the public research phase, with concrete data, not from the announcement stage. As soon as a consensus signature scheme is available on the testnet, we offer to test it, openly document the process, and share the findings with the community, as we always do.

In blockchain, validators are the engine that makes it possible, and the community is the fuel that keeps that engine running.

Sources:

• StarkWare, “The Architecture Advantage: Starknet’s Quantum Readiness Roadmap” (June 30, 2026), the official roadmap announcement, with the three phases and their estimated timelines: https://starkware.co/blog/the-architecture-advantage-starknets-quantum-readiness-roadmap/
• StarkWare, “Quantum security for everyone: the StarkWare Quantum Hub is now live” (July 30, 2026), hub launch and link to the transaction on X: https://starkware.co/blog/quantum-hub/
• StarkWare Post-Quantum Migration Tracking Dashboard: https://quantum.starkware.co/
• Starknet’s Decentralization Roadmap (last updated March 22, 2026) places post-quantum cryptography in Phase 4, alongside Staking v3 and v4: https://www.starknet.io/roadmap/
• SNIP-32 thread in the Starknet forum, “Expose Keccak-f[1600] Permutation Syscall” (July 2025): https://community.starknet.io/t/snip-32-expose-keccak-f-1600-permutation-syscall/115770
• s2morrow, demo and deployment of the Falcon-512 in Cairo, with gas and compression figures: https://www.s2morrow.xyz/ and https://github.com/feltroidprime/s2morrow
• StarkWare, “Starknet’s Quantum Edge: STARKs and Native Account Abstraction” (20 de julio de 2026): https://starkware.co/blog/starknets-quantum-edge-starks-and-native-account-abstraction/

Follow us on: Twitter | Medium | LinkedIn | Discord | cumulo.pro
or our news channel on Telegram

Starknet was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hace unas semanas, una wallet en Starknet hizo una transferencia real firmada con Falcon-512, un esquema de firma que ningún ordenador cuántico, ni uno mucho más potente que los que existen hoy, puede falsificar. Costó unos seis céntimos, la cuenta es experimental y no auditada, y la transacción quedó registrada en mainnet, pública.

Por qué importa: la criptografía que protege prácticamente todas las wallets hoy (Bitcoin, Ethereum, la mayoría de L2s) se basa en curva elíptica, y curva elíptica es exactamente lo que un ordenador cuántico lo bastante potente puede romper. Esa transferencia es la prueba de que ya existe, en producción, una alternativa que no depende de esa criptografía. Pero es solo la pieza más visible de una historia más larga: por qué Starknet pudo hacer esto sin fork ni migración forzada, qué tan resuelto está realmente el resto del roadmap, y qué queda por construir en la pieza menos visible de todas, el consenso que sostiene la red por debajo.

El riesgo cuántico ya está activo, aunque el hardware no exista aún

La exposición cuántica de una blockchain no empieza el día que exista un ordenador cuántico capaz de romper curvas elípticas. Empieza antes, bajo el modelo conocido como harvest now, decrypt later: un atacante puede archivar hoy datos on-chain cifrados y descifrarlos en cuanto el hardware esté disponible. La pregunta relevante no es cuándo llegará ese hardware, sino cuánto trabajo de migración le queda a una red antes de ese momento.

Toda blockchain tiene dos frentes de exposición independientes. La capa de cuenta: la firma que autoriza cada transacción. Y la capa de verificación: el sistema de pruebas que garantiza que el estado de la cadena es válido. Bitcoin y Ethereum tienen curva elíptica cableada en ambas. La mayoría de zk-rollups también, porque construyen sus SNARKs sobre curvas elípticas. Resolver solo una de las dos capas no resuelve el problema.

Por qué Starknet parte de otro punto

En la capa de verificación, Starknet corre sobre STARKs: pruebas basadas en funciones hash, no en curvas elípticas. No existe ataque cuántico conocido contra una función hash, el mejor disponible, el algoritmo de Grover, solo acelera la fuerza bruta, y se compensa aumentando el tamaño del hash. Es una propiedad estructural del sistema de pruebas, presente desde el diseño original, años antes de que esto fuera tema de conversación en la industria.

En la capa de cuenta, cada cuenta en Starknet es un smart contract: ningún esquema de firma está fijado en el protocolo, cada cuenta decide qué acepta en su propia lógica. Eso es lo que hizo posible la transferencia sin hard fork, sin migración coordinada y sin cambio de dirección.

La historia que no ha contado nadie: el coste real de Falcon-512

Aquí hay algo que no salió en ningún titular, y que vale la pena contar. Verificar una firma dentro de un contrato de Starknet no es gratis: cada operación tiene un coste en la red, y cuanto más compleja es la firma, más cara resulta verificarla. Con Falcon-512 ese coste era, hasta hace relativamente poco, un problema real y sin resolver.

En julio de 2025, casi un año antes del roadmap oficial, un desarrollador de la comunidad planteó en el foro público de Starknet una forma de abaratar ese coste. Un investigador de StarkWare le respondió con honestidad: no era suficiente. Una de las operaciones internas que necesita Falcon-512 seguía siendo demasiado pesada, tan cerca del límite de lo que un contrato puede soportar que ni siquiera estaba claro que fuera viable en la práctica. Fue una conversación técnica abierta, sin garantías de que fuera a funcionar.

Un año después, sí funciona. La implementación de Falcon-512 que corre hoy en mainnet resolvió ese problema: verificar una firma cuesta bastante menos que otras alternativas comparables que ya usan muchas wallets, y cabe con margen dentro de los límites de un contrato de Starknet. Es la misma firma que hizo posible la transferencia de seis céntimos con la que abríamos este artículo. Lo relevante no es solo que hoy funcione , es que todo el proceso, desde la duda inicial hasta la solución, ocurrió en público, en el foro de Starknet, mucho antes de que nadie hablara de esto en los medios.

El roadmap y su estado real, superficie por superficie

El roadmap post-cuántico de StarkWare, publicado el 30 de junio, plantea tres fases: asegurar la actividad nueva, dar herramientas de migración a los contratos existentes, y por último resolver las dependencias compartidas con Ethereum. Starknet mantiene un registro público de avance (quantum.starkware.co) con el estado real de cada superficie, que conviene citar con precisión en vez de dar por hecho que todo está resuelto:

Ya en marcha, en mainnet. Starknet cambió una de las funciones matemáticas internas que usa para sellar el estado de la red por una versión resistente a la cuántica (en la jerga técnica: sustituyó Pedersen por BLAKE2s-256 en los hashes de configuración del sistema).

Anunciado, pero todavía no activo. El mismo tipo de cambio para la estructura que guarda los datos de cada contrato y para cómo se calculan las direcciones de las cuentas. Se sabe qué se va a hacer y cómo, pero todavía no está desplegado en producción.

En fase de investigación, sin fecha ni herramienta pública todavía. Cómo migrar los contratos que ya existen y que guardan su información con el método antiguo. Es la parte más delicada, porque afecta a lo que ya está desplegado y en uso, y StarkWare aún no ha publicado un plan concreto de cómo hacerlo sin romper nada.

Fuera del control directo de Starknet. Parte de los datos de la red se publican en Ethereum, y esa pieza sigue usando una criptografía que Ethereum todavía no ha actualizado (el mecanismo se llama KZG). Lo mismo ocurre con el puente entre ambas redes. Aquí Starknet depende del calendario de Ethereum, no solo del suyo.

La pieza que casi nadie está conectando: consenso y validación descentralizada

Casi toda la conversación pública sobre este roadmap se ha centrado en la cuenta Falcon-512. Pero hay un dato que rara vez se menciona junto al anuncio: el roadmap oficial de descentralización de Starknet ubica la criptografía post-cuántica en la misma fase: Fase 4, actualmente en curso, que Staking v3 (validación de bloques descentralizada) y Staking v4 (consenso y operación de red totalmente descentralizados). No es una coincidencia de calendario: StarkWare ha señalado explícitamente firmas de consenso post-cuánticas, con Falcon-512 como candidato, pensadas para el momento en que la validación deje de depender de StarkWare y pase a manos de un set de validadores independientes.

Esa es la parte que nos toca directamente como validador, y donde el problema deja de ser “¿mi wallet acepta otra firma?” para pasar a ser “¿qué firma tendrá que soportar el software de nodo que opera cada validador, con qué antelación habrá una especificación pública, y habrá una ventana de testnet real antes de que sea obligatorio en mainnet?”. Son preguntas de infraestructura, no de UX, y preferimos plantearlas ahora, en fase de investigación, igual que se planteó y resolvió el coste de Falcon-512 en el foro hace un año, y no cuando la validación descentralizada ya esté en producción.

Desde Cumulo

Llevamos más de 5 años operando infraestructura de validación no custodia en distintas redes, Starknet incluida, con herramientas open source propias para monitorización y despliegue. Este es exactamente el tipo de decisión de protocolo que preferimos seguir desde la fase de investigación pública, con datos concretos, no desde el anuncio. En cuanto haya un esquema de firma de consenso disponible en testnet, nos ofrecemos a probarlo, documentar el proceso en abierto y compartir los hallazgos con la comunidad, como publicamos siempre.

En blockchain, los validadores son el motor que lo hace posible y la comunidad es el combustible que mantiene ese motor en marcha.

Fuentes:

• StarkWare, “The Architecture Advantage: Starknet’s Quantum Readiness Roadmap” (30 de junio de 2026), el anuncio oficial del roadmap, con las tres fases y sus tiempos estimados: https://starkware.co/blog/the-architecture-advantage-starknets-quantum-readiness-roadmap/
• StarkWare, “Quantum security for everyone: the StarkWare Quantum Hub is now live” (30 de julio de 2026), lanzamiento del hub y enlace a la transacción en X: https://starkware.co/blog/quantum-hub/
• Panel de seguimiento de la migración post-cuántica de StarkWare: https://quantum.starkware.co/
• Starknet, Decentralization Roadmap (última actualización 22 de marzo de 2026), ubica la criptografía post-cuántica en la Fase 4, junto a Staking v3 y v4: https://www.starknet.io/roadmap/
• Hilo SNIP-32 en el foro de Starknet, “Expose Keccak-f[1600] Permutation Syscall” (julio de 2025): https://community.starknet.io/t/snip-32-expose-keccak-f-1600-permutation-syscall/115770
• s2morrow, demo e implementación de Falcon-512 en Cairo, con cifras de gas y compresión: https://www.s2morrow.xyz/ y https://github.com/feltroidprime/s2morrow
• StarkWare, “Starknet’s Quantum Edge: STARKs and Native Account Abstraction” (20 de julio de 2026): https://starkware.co/blog/starknets-quantum-edge-starks-and-native-account-abstraction/

Síguenos en: Twitter | Medium | LinkedIn | Discord | cumulo.pro
O nuestro canal de noticias en telegram

Starknet was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Table of Contents

In this guide you will learn how to deploy Horcrux, a multi-party-computation (MPC) signing service that protects your Cosmos validator’s private key by sharding it across multiple nodes.

We will use a model with 3 signer nodes and 2 sentry nodes to achieve fault tolerance and maximum security.

Introduction

The security of private keys is one of the most sensitive aspects of operating a validator node. A leak, loss, or duplicate signature can have serious consequences, ranging from the loss of funds to expulsion from the network for double-signing.

This is where Horcrux comes in, a tool developed by Strangelove that implements distributed signature using MPC (Multi-Party Computation) specifically designed for nodes based on Cosmos SDK and CometBFT.

Horcrux fragments the validator’s private key into multiple shards using Shamir’s Secret Sharing and delegates block signing to a cluster of signers. This way, even if one of the signing nodes fails or is compromised, the signing process can continue without the risk of double-signing or security loss. The complete private key never exists on any server during operation; only individual shards exist, and these shards cannot sign anything on their own.

In this guide, we apply this architecture to Cosmos Hub, using a 2-out-of-3 configuration: block signing requires agreement from at least two of the three signers. This is the recommended configuration to maximize resilience without sacrificing availability.

Architecture

Implemented model

- 🔐 3 Signing Nodes (Signers): distribute the signature using MPC

- 🛰️ 2 Sentry nodes: serve as a secure interface between the network and the signers

📌 Each signers communicates with both sentinels through the private validation port.

Hardware requirements

- Sentry: Baremetal (according to Cosmos Hub requirements). Data centers with public connectivity.

- Signer: VPS: 1 CPU/ 1 GB RAM / 20GB SSD NVMe / 100 Mbps. Providers in separate regions for greater resilience.

Network and firewall configuration

To ensure system security and connectivity, apply the following port configuration:

Signers

- Open port 2222to receive signature requests, only from the IPs of the sentinels.

- Keep only the following open: SSH and, if used, Prometheus.

- ❌ Close all other external access.

Sentry Nodes

- Expose validation ports ( 1234, 1235) only to signers, never to the public Internet.

- The port 26656(P2P) must be publicly open for the node to participate in consensus and discover peers.

🔒 Important: The validator’s private key must not exist on the sentinels. They only receive requests from Horcrux to sign blocks.

Horcrux Installation

Install Horcrux on the three signers:

mkdir horcrux_cosmos
cd horcrux_cosmos

wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.3/horcrux_linux-amd64
mv horcrux_linux-amd64 horcrux
sudo cp horcrux /usr/local/bin/
sudo chmod +x /usr/local/bin/horcrux

horcrux version

Initialize shared configuration

From a single machine, generate the network configuration between signers and sentries. In this case, we have 2 sentries and 3 signers :

horcrux config init \
  --node "tcp://<sentry-1>:1234" \
  --node "tcp://<sentry-2>:1235" \
  --cosigner "tcp://<signer-1>:2222" \
  --cosigner "tcp://<signer-2>:2222" \
  --cosigner "tcp://<signer-3>:2222" \
  --threshold 2 \
  --grpc-timeout 1000ms \
  --raft-timeout 1000ms

This will generate the file config.yamlthat must be distributed to each signer under ~/.horcrux/.

Create shared keys

ECIES (communication between signers)

horcrux create-ecies-shards - shards 3

This will generate a pair of encrypted keys for secure communication between signers:

cosigner_1/ecies_keys.json
cosigner_2/ecies_keys.json
cosigner_3/ecies_keys.json

⚠️ Each shard should only be copied to the signer it belongs to. Once distributed, no single node has the complete key. Move it priv_validator_key.jsonto a secure offline location immediately.

Fragmentar clave privada del validador

Copy your priv_validator_key.jsoncurrent directory and run:

horcrux create-ed25519-shards \
  --chain-id provider \
  --key-file ./priv_validator_key.json \
  --threshold 2 \
  --shards 3

The list of fragmented signature files will appear:

Created Ed25519 Shard cosigner_1/provider_shard.json
Created Ed25519 Shard cosigner_2/provider_shard.json
Created Ed25519 Shard cosigner_3/provider_shard.json

⚠️ Each shard should only be copied to the signer it belongs to. Once distributed, no node has the complete key.

Share the consensus status among signers

This step prevents accidental duplicate signatures. Each signer must start with the same priv_validator_state.json, which represents the last signed block.

🛑 Stop original validator node

sudo systemctl stop gaiad

📄 View current status content:

cat ~/.gaia/data/priv_validator_state.json

{
  "height": "XXXXXX",
  "round": 0,
  "step": 3,
  "signature": "...",
  "signbytes": "..."
}

✂️ Create truncated version (remove signatureand signbytes):

{
  "height": "XXXXXX",
  "round": 0,
  "step": 3
}

📁 Copy each signer to the route:

~/.horcrux/state/provider_priv_validator_state.json

Repeat this step for all three signers before starting Horcrux.

Create the Horcrux service

For each signer, create and activate the systemd service:

sudo tee /etc/systemd/system/horcrux.service > /dev/null <<EOF
[Unit]
Description=MPC Signer node
After=network-online.target

[Service]
User=$USER
WorkingDirectory=/home/$USER
ExecStart=$(which horcrux) start
Restart=on-failure
RestartSec=3
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable horcrux
sudo systemctl start horcrux
sudo journalctl -u horcrux -f

Configure Sentry nodes

Activate signature endpoint

In each sentry, edit config.tomlto enable listening for the remote validator. Adjust the port according to the sentry ( 1234or 1235):

sed -i 's#priv_validator_laddr = ""#priv_validator_laddr = "tcp://0.0.0.0:1234"#g' ~/.gaia/config/config.toml

Confirm:

grep priv_validator_laddr ~/.gaia/config/config.toml

🚫 Delete private key from sentry: WARNING this is a critical step. Make sure Horcrux is working correctly before running it.

rm ~/.gaia/config/priv_validator_key.json

🔁 Restart node:

sudo systemctl restart gaiad
journalctl -u gaiad -f

✅ Verification

For each signer, check the Horcrux logs:

journalctl -u horcrux -f

Expected messages:

✅ Successfully signed proposal at height XXXXXX

If all three signers show coordinated signing activity, the implementation is correct.

Good practices

- 🛡️ Secure the ports: only signers should have access to the sentinel validation ports.

- 🗃️ Make backups of provider_shard.json, ecies_keys.jsonand config.yamlstore them in a safe, offline location.

- 🔄 Document which file belongs to which signatory to facilitate recovery in case of incidents.

- 🌍 Distribute signers across different providers and regions to avoid common points of failure.

- ⚠️ Do not start Horcrux on signers before you have copied the truncated consensus state.

🔗 Useful resources

- Horcrux Repository

- Architecture recommended by Cumulo

- Implementation documentation in Cosmos Testnet

Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro

How to run Horcrux on Cosmos was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.

Índice de contenidos

· Introducción
· Arquitectura
· Configuración de red y firewall
· Instalación de Horcrux
· Inicializar configuración compartida
· Crear claves compartidas
· Compartir el estado de consenso entre firmantes
· Crear el servicio Horcrux
· Configurar nodos Sentry
· Buenas prácticas
· Recursos útiles

En esta guía aprenderás a desplegar Horcrux, una herramienta de firma distribuida (MPC) que protege la clave privada de tu validador de Cosmos al fragmentarla entre múltiples nodos.

Usaremos un modelo con 3 nodos firmantes (signers) y 2 nodos centinelas (sentry nodes) para lograr tolerancia a fallos y máxima seguridad.

Introducción

La seguridad de las claves privadas es uno de los puntos más sensibles en la operación de un nodo validador. Una filtración, pérdida o firma duplicada puede tener consecuencias graves: desde la pérdida de fondos hasta la expulsión de la red por doble firma.

Aquí es donde entra en juego Horcrux, una herramienta desarrollada por Strangelove que implementa firma distribuida mediante MPC (Multi-Party Computation) específicamente diseñada para nodos basados en Cosmos SDK y CometBFT.

Horcrux fragmenta la clave privada del validador en múltiples partes (shards) usando Shamir’s Secret Sharing y delega la firma de bloques a un clúster de firmantes. De este modo, incluso si uno de los nodos firmantes falla o está comprometido, la firma puede continuar sin riesgo de doble firma ni pérdida de seguridad. La clave privada completa nunca existe en ningún servidor durante la operación, solo existen fragmentos individuales que por sí solos no pueden firmar nada.

En esta guía aplicamos esta arquitectura en Cosmos Hub, utilizando una configuración 2 de 3: la firma de bloques requiere el acuerdo de al menos 2 de los 3 firmantes. Esta es la configuración recomendada para maximizar resiliencia sin sacrificar disponibilidad.

Arquitectura

Modelo implementado

- 🔐 3 nodos firmantes (Signers): distribuyen la firma mediante MPC

- 🛰️ 2 nodos centinela (Sentry): sirven como interfaz segura entre la red y los firmantes

📌 Cada firmante se comunica con ambos centinelas a través del puerto privado de validación.

Requisitos de hardware

- Sentry: Baremetal (según los requisitos de Cosmos Hub). Centros de datos con conectividad pública.

- Signer: VPS: 1 CPU/ 1 GB RAM / 20GB SSD NVMe / 100 Mbps. Proveedores en regiones separadas para mayor resiliencia.

Configuración de red y firewall

Para garantizar la seguridad y conectividad del sistema, aplica la siguiente configuración de puertos:

Signers

- Abrir el puerto 2222 para recibir solicitudes de firma, solo desde las IPs de los centinelas.

- Mantener abiertos únicamente: SSH y, si se usa, Prometheus.

- ❌ Cerrar todo el resto al acceso externo.

Sentry Nodes

- Exponer los puertos de validación ( 1234, 1235) solo hacia los firmantes, nunca hacia Internet pública.

- El puerto 26656 (P2P) debe estar abierto públicamente para que el nodo participe en el consenso y descubra peers.

🔒 Importante: La clave privada del validador no debe existir en los centinelas. Solo reciben solicitudes desde Horcrux para firmar bloques.

Instalación de Horcrux

Instala Horcrux en los tres firmantes:

mkdir horcrux_cosmos
cd horcrux_cosmos

wget https://github.com/strangelove-ventures/horcrux/releases/download/v3.2.3/horcrux_linux-amd64
mv horcrux_linux-amd64 horcrux
sudo cp horcrux /usr/local/bin/
sudo chmod +x /usr/local/bin/horcrux

horcrux version

Inicializar configuración compartida

Desde una sola máquina, genera la configuración de red entre firmantes y centinelas. En este caso contamos con 2 sentries y 3 signers:

horcrux config init \
  --node "tcp://<sentry-1>:1234" \
  --node "tcp://<sentry-2>:1235" \
  --cosigner "tcp://<signer-1>:2222" \
  --cosigner "tcp://<signer-2>:2222" \
  --cosigner "tcp://<signer-3>:2222" \
  --threshold 2 \
  --grpc-timeout 1000ms \
  --raft-timeout 1000ms

Esto generará el fichero config.yaml que deberá distribuirse a cada firmante bajo ~/.horcrux/ .

Crear claves compartidas

ECIES (comunicación entre firmantes)

horcrux create-ecies-shards - shards 3

Esto generará un par de claves cifradas para la comunicación segura entre signers:

cosigner_1/ecies_keys.json
cosigner_2/ecies_keys.json
cosigner_3/ecies_keys.json

⚠️ Cada shard debe copiarse únicamente al firmante que le corresponde. Una vez distribuidos, ningún nodo dispone de la clave completa. Mueve priv_validator_key.jsona un lugar seguro offline inmediatamente.

Fragmentar clave privada del validador

Copia tu priv_validator_key.json al directorio actual y ejecuta:

horcrux create-ed25519-shards \
  --chain-id provider \
  --key-file ./priv_validator_key.json \
  --threshold 2 \
  --shards 3

Aparecerá la lista de ficheros de firma fragmentada:

Created Ed25519 Shard cosigner_1/provider_shard.json
Created Ed25519 Shard cosigner_2/provider_shard.json
Created Ed25519 Shard cosigner_3/provider_shard.json

⚠️ Cada shard debe copiarse solo al firmante que le corresponde. Una vez distribuidos, ningún nodo dispone de la clave completa.

Compartir el estado de consenso entre firmantes

Este paso previene firmas dobles accidentales. Cada firmante debe arrancar con el mismo priv_validator_state.json, que representa el último bloque firmado.

🛑 Detener nodo validador original

sudo systemctl stop gaiad

📄 Ver contenido del estado actual:

cat ~/.gaia/data/priv_validator_state.json

{
  "height": "XXXXXX",
  "round": 0,
  "step": 3,
  "signature": "...",
  "signbytes": "..."
}

✂️ Crear versión truncada (elimina signature y signbytes):

{
  "height": "XXXXXX",
  "round": 0,
  "step": 3
}

📁 Copiar a cada firmante en la ruta:

~/.horcrux/state/provider_priv_validator_state.json

Repite este paso en los tres firmantes antes de arrancar Horcrux.

Crear el servicio Horcrux

En cada firmante, crea y activa el servicio systemd:

sudo tee /etc/systemd/system/horcrux.service > /dev/null <<EOF
[Unit]
Description=MPC Signer node
After=network-online.target

[Service]
User=$USER
WorkingDirectory=/home/$USER
ExecStart=$(which horcrux) start
Restart=on-failure
RestartSec=3
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable horcrux
sudo systemctl start horcrux
sudo journalctl -u horcrux -f

Configurar nodos Sentry

Activar endpoint de firma

En cada sentry, edita config.toml para activar la escucha del validador remoto. Ajusta el puerto según el sentry ( 1234 o 1235):

sed -i 's#priv_validator_laddr = ""#priv_validator_laddr = "tcp://0.0.0.0:1234"#g' ~/.gaia/config/config.toml

Confirmar:

grep priv_validator_laddr ~/.gaia/config/config.toml

🚫 Eliminar clave privada del sentry: ATENCIÓN este es un paso crítico. Asegúrate de que Horcrux está funcionando correctamente antes de ejecutarlo.

rm ~/.gaia/config/priv_validator_key.json

🔁 Reiniciar nodo:

sudo systemctl restart gaiad
journalctl -u gaiad -f

✅ Verificación

En cada firmante, comprueba los logs de Horcrux:

journalctl -u horcrux -f

Mensajes esperados:

✅ Successfully signed proposal at height XXXXXX

Si los tres firmantes muestran actividad coordinada de firma, la implementación es correcta.

Buenas prácticas

- 🛡️ Asegura los puertos: solo los firmantes deben tener acceso a los puertos de validación de los centinelas.

- 🗃️ Realiza backups de provider_shard.json, ecies_keys.json y config.yaml en un lugar seguro y offline.

- 🔄 Documenta qué archivo pertenece a qué firmante para facilitar la recuperación ante incidentes.

- 🌍 Distribuye los firmantes entre diferentes proveedores y regiones para evitar puntos de fallo comunes entre los firmantes.

- ⚠️ No arranques Horcrux en los firmantes antes de haber copiado el estado de consenso truncado.

🔗 Recursos útiles

- Repositorio Horcrux

- Arquitectura recomendada por Cumulo

- Documentación de implementación en Cosmos Testnet

Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro

Cómo implementar Horcrux en Cosmos was originally published in Cumulo.pro on Medium, where people are continuing the conversation by highlighting and responding to this story.