Forem: Alex Pestchanker

🧠 De Bitcoin a Midnight: la evolución real de la usabilidad en blockchain (vista por y para developers) 🇪🇸

Alex Pestchanker — Tue, 14 Apr 2026 14:27:33 +0000

Cuando hablamos de generaciones de blockchain, muchas veces nos quedamos en slogans:
“dinero digital”, “smart contracts”, “escalabilidad”, “privacidad”.

Pero hay una forma mucho más útil de entender esta evolución:

👉 ¿Cómo cambia la vida de un developer en cada generación?
👉 ¿Qué tan fácil es construir, integrar y llevar algo a producción?

En este artículo comparo las 4 generaciones de blockchains con un mismo marco:
• Propuesta de valor
• Developer Experience (DX)
• Cómo se integra
• Problemas encontrados
• Mejores prácticas

🟠 Generación 1 — Bitcoin: Seguridad antes que usabilidad

🧩 Propuesta de valor

Dinero digital descentralizado, resistente a censura y sin intermediarios.

👨‍💻 Developer Experience
• Lenguaje: Script (limitado, no Turing completo)
• Modelo: UTXO
• Paradigma: extremadamente restrictivo

Bitcoin no está pensado para que desarrolles lógica compleja.
Está pensado para minimizar superficie de ataque.

🔌 Cómo se integra
• Lectura de blockchain vía nodos o APIs
• Construcción y firma de transacciones
• Custodia (wallets, hardware wallets)

👉 El desarrollo ocurre casi todo fuera de la cadena.

⚠️ Problemas encontrados
• No hay programabilidad real
• Difícil extender a otros casos de uso
• UX dependiente de herramientas externas

✅ Mejores prácticas
• Mantener lógica fuera de la cadena
• Usar Bitcoin como capa de settlement
• Evitar “forzar” casos de uso no nativos

👉 Resúmen:
No construís sobre Bitcoin. Construís alrededor de Bitcoin.

:::::

🟣 Generación 2 — Ethereum (v1): Programabilidad con costo

🧩 Propuesta de valor

Una computadora global donde podés desplegar lógica programable (smart contracts).

👨‍💻 Developer Experience
• Lenguaje: Solidity
• Modelo: Account-based
• Runtime: EVM

Por primera vez, podés programar la blockchain directamente.

🔌 Cómo se integra
• Deploy de smart contracts
• Frontend conectado vía Web3
• Interacción mediante wallets

👉 Todo gira en torno a contratos on-chain.

⚠️ Problemas encontrados
• Fees altos e impredecibles
• UX frágil (firmas constantes, wallets complejas)
• Bugs críticos irreversibles
• Escalabilidad limitada

✅ Mejores prácticas
• Minimizar lógica on-chain
• Auditar contratos rigurosamente
• Diseñar UX considerando fricción de firma
• Usar patrones estándar (OpenZeppelin, etc.)

👉 Resúmen:
Podés construir, pero el costo en complejidad y UX es altísimo.

:::::

🔵 Generación 3 — Cardano, Avalanche, XRP, Ethereum v2: Escalabilidad e integración

🧩 Propuesta de valor

Convertir blockchain en una infraestructura usable a escala, integrable con sistemas reales.

Incluye:
• Cardano (eUTXO + verificación formal)
• Avalanche (subnets, custom chains)
• XRP (infra financiera)
• Ethereum v2 (PoS + escalabilidad progresiva)

👨‍💻 Developer Experience
• Modelos más diversos (eUTXO, subnets, PoS)
• Mejor tooling, testing y frameworks
• Separación clara on-chain / off-chain

👉 Se empieza a pensar en arquitectura completa, no solo contratos.

🔌 Cómo se integra
• Backend tradicional + blockchain
• Indexers, APIs, oráculos
• Servicios intermedios

👉 La blockchain pasa a ser una capa dentro del sistema, no el sistema completo.

⚠️ Problemas encontrados
• Mayor complejidad arquitectónica
• Curva de aprendizaje alta (especialmente eUTXO)
• Infra adicional (indexers, nodos, servicios)
• UX aún dependiente de wallets

✅ Mejores prácticas
• Diseñar sistemas híbridos
• Definir claramente responsabilidades on/off-chain
• Optimizar uso de la blockchain (no todo va on-chain)
• Testing formal (especialmente en modelos funcionales)

👉 Resúmen Gen3:
Ya no construís “dApps”. Construís sistemas distribuidos completos.

:::::

⚫ Generación 4 — Midnight: Casos de uso + privacidad por diseño

🧩 Propuesta de valor

Privacidad, usabilidad real y abstracción total de la complejidad blockchain.

👨‍💻 Developer Experience
• Lenguaje: Compact
• Modelo: commitments + pruebas ZK
• Ejecución:
- Off-chain → generación de pruebas
- On-chain → verificación

👉 El usuario (y la dapp) controla qué se revela y qué no.

🔌 Cómo se integra
• Generación de proofs en cliente o backend
• Publicación de commitments en la chain
• UX desacoplada de la blockchain

👉 El usuario no interactúa directamente con la blockchain.

⚠️ Problemas encontrados
• Curva conceptual (ZK, commitments, proofs)
• Tooling aún en evolución
• Debugging más complejo
• Nuevos modelos mentales para developers

✅ Mejores prácticas
• Diseñar “privacy-first” desde el inicio
• Minimizar datos expuestos
• Mover lógica fuera de la chain cuando sea posible
• Pensar en UX Web2 con garantías Web3

👉 Resúmen Gen4:
La blockchain deja de ser visible. Se vuelve infraestructura invisible al servicio de la experiencia.

:::::

🔄 Comparación directa (modo developer)

Generación	Propuesta	Qué hace el dev	Lógica	UX
Gen1	Dinero digital	Integra pagos	Off-chain	Simple
Gen2	Programabilidad	Escribe contratos	On-chain	Compleja
Gen3	Escala + integración	Diseña sistemas	Mixto	Mejor
Gen4	UX + privacidad	Diseña experiencias	Off-chain + ZK	Invisible

🧭 Conclusión (lo que realmente cambió)

La evolución de blockchain no es solo técnica. Es una transición profunda en cómo construimos:
• De infraestructura financiera → Bitcoin
• A plataforma programable → Ethereum v1
• A sistemas integrados reales → Cardano, Avax, Eth v2
• A experiencias centradas en el usuario → Midnight

Pero el cambio más importante es este:

👉 Dónde vive la complejidad
• Antes: en el usuario
• Después: en el developer
• Ahora: en la arquitectura

Y esto redefine completamente el rol del developer:

Ya no es alguien que “escribe contratos”.

👉 Es alguien que diseña sistemas donde:
• la confianza está garantizada
• la privacidad está protegida
• y la experiencia es simple

Porque al final:

El usuario no quiere saber qué es un smart contract.
No quiere entender un UTXO.
No quiere firmar 5 veces una transacción.

👉 Solo quiere QUE LE SOLUCIONES SUS PROBLEMAS!

Selective Disclosure & Self-Managing DIDs for AI Agents

Alex Pestchanker — Tue, 31 Mar 2026 15:32:42 +0000

Closing the Identity Gap in the Age of Autonomous Systems

A practical walkthrough to address the identity and security gap in autonomous AI systems.

1. The Exponential Rise of AI Agents
In the last few months, we’ve witnessed something unusual even for exponential tech standards:
AI agents are not just improving, they’re being adopted at extreme velocity.

Projects like OpenClaw, OpenFang, PaperClip, AutoGPT, and newer agent frameworks have reached:
• Thousands of GitHub stars in weeks
• Active developer ecosystems almost instantly
• Real-world experimentation (automation, trading, social agents)

“OpenClaw reached comparable adoption milestones in a fraction of the time of previous-generation AI frameworks, reinforcing the hypothesis that agent-based systems follow a compressed exponential adoption curve.”

This is not just growth — it resembles a phase transition in software adoption.

Key Insight

The barrier to creating autonomous software has collapsed:
• LLM APIs → cognition layer
• Tooling frameworks → action layer
• Open ecosystems → distribution layer

👉 Result: Anyone can deploy semi-autonomous agents with real-world capabilities.

2. The Hidden Problem: A Massive Security Vacuum
While adoption exploded, security and identity did not evolve at the same pace.

Today’s agents commonly:
• Store API keys in plain text or env files
• Access personal data (emails, documents, wallets)
• Execute transactions (crypto, payments, APIs)
• Act on behalf of users with minimal constraint

And yet:

There is no standardized identity, permission, or trust framework for agents.

This creates a dangerous asymmetry:

Capability	Maturity
Autonomy	High
Intelligence	High
Access to sensitive data	High
Identity & trust model	Extremely low

We are effectively deploying:

Autonomous entities with root-level access… and no formal identity layer.

3. Why DIDs Matter — But Are Not Enough
The introduction of Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) — standardized by the W3C DIDs and VCs specifications — is a critical step forward.

They provide:
• Self-sovereign identity
• Cryptographic verification
• Interoperable trust frameworks

However, in practice, a key question remains unanswered:

How do agents actually manage, use, and protect these identities and credentials autonomously?

The Missing Layer

DIDs define:
• What identity is
• How it is verified

But they do NOT define:
• How an agent stores credentials securely
• How information is selectively disclosed
• How secrets are managed during runtime
• How identity evolves over time
• How risk is constrained

👉 This is the Agent Identity Orchestration Gap.

4. Selective Disclosure as a Core Primitive
In a world of autonomous agents, Selective Disclosure is not optional, it is foundational.

Instead of exposing full identity or credentials, agents must:
• Reveal only required attributes
• Prove statements without leaking raw data
• Maintain privacy across interactions

Examples:
• “Payment Authorized” without revealing wallet balance
• “KYC verified” without sharing identity
• “Valid Agent Identity” without exposing owner

This aligns perfectly with:

Privacy-preserving computation + zero-knowledge systems

Which leads us to the enabling infrastructure.

5. Enter Midnight: A Missing Execution Layer
The recently launched Midnight Network introduces a missing capability:

Programmable privacy with selective disclosure and confidential computation

This makes it uniquely suited to become:

👉 The Identity & Trust Execution Layer for AI Agents

Capabilities include:
• Confidential smart contracts
• Shielded data handling
• Selective disclosure primitives
• Verifiable off-chain + on-chain logic

6. Proposed Architecture
6.1 High-Level Overview

“This layered architecture introduces a separation of concerns between decision-making, identity, and secret management. By isolating credentials within a secure Agent Vault and enabling selective disclosure via Midnight, agents can operate autonomously without exposing sensitive data or compromising trust.”

7. Core Components

These components are not optional — they represent a minimum viable security boundary for autonomous agents.

7.1 Agent DID

Each agent has:
• A unique DID
• Public/private key pair
• Associated verifiable credentials

This allows:
• Authentication
• Trust verification
• Inter-agent communication

7.2 Agent Vault (Critical Component)

The Agent Vault is the missing piece in most current systems.

It acts as:

🔐 A secure execution boundary for identity and secrets

Responsibilities:
• Store private keys
• Store verifiable credentials
• Manage API keys securely
• Enforce access policies

Key design principle:

The agent never directly handles raw secrets — it requests controlled access from the vault.

7.3 Credential Manager
Handles:
• Issuance of credentials
• Storage and indexing
• Lifecycle management (expiry, revocation)
• Selective disclosure generation

7.4 Selective Disclosure Engine
Built on Midnight capabilities:
• Generates proofs instead of raw data
• Controls what is revealed per interaction
• Enforces least-privilege disclosure

7.5 Policy Engine
Defines:
• What the agent is allowed to do
• Under what conditions
• With which credentials

Examples:
• “Can execute payments < $500”
• “Requires human approval above threshold”
• “Can access email metadata but not content”

7.6 Interaction Gateway
Handles external interactions:
• APIs/MCPs/ACPs
• Wallets
• Other agents

Ensures:
• All actions are identity-backed
• All disclosures are policy-compliant

8. Identity Flow (End-to-End)

"This flow defines how identity, policy, and execution interact in a closed-loop system, ensuring that every action is both authorized and privacy-preserving."

9. MVP Implementation: Agent DID Manager on Midnight
To move beyond theory, this research is grounded in a working prototype:

👉 https://github.com/apestchanker/midnight-agent-did-manager

This repository represents an early Minimum Viable Implementation (MVP) of a self-managed identity system for AI agents, designed to explore how DIDs and Verifiable Credentials can be programmatically created, managed, and used by autonomous systems.

It is important to clarify:

⚠️ This is work in progress (incomplete) and a research prototype, not production-ready infrastructure.

However, it demonstrates critical primitives required for the next generation of agent identity systems.

9.1 What the MVP Demonstrates

The implementation showcases how an AI agent can:
• Generate and manage its own Decentralized Identifier (DID)
• Associate and store Verifiable Credentials (VCs) (partially)
• Structure identity data in a way that is machine-native and automatable
• Prepare credentials for selective disclosure workflows

Unlike traditional identity systems, where identity is user-managed, this prototype explores:

Agents as first-class citizens

9.2 Midnight as an Enabling Layer

A key innovation explored in this MVP is the integration path with Midnight Network as the execution and privacy layer.

Midnight introduces capabilities that are essential for agent identity systems:

🔒 Confidential Data Handling
Sensitive identity data (credentials, claims, attributes) can be processed without being publicly exposed.

This enables:
• Private credential verification
• Secure agent-to-agent interactions
• Protection of identity metadata

🧩 Selective Disclosure Primitives
Instead of sharing full credentials, agents can:
• Prove specific attributes
• Minimize data exposure
• Enforce privacy by default

This is critical for autonomous systems operating at scale.

🔁 Trusted Exchange of Identity and Selective Disclosure VCs
Midnight can act as a neutral coordination layer where:
• Agents present proofs
• Counterparties verify without accessing raw data
• Interactions become trust-minimized and verifiable

9.3 Current Limitations (and Why They Matter)

While the MVP demonstrates identity creation and structuring, it intentionally does not yet include:
• Secure secret isolation
• Runtime policy enforcement
• Hardware-backed key management
• Full selective disclosure circuits

These gaps are not shortcomings — they define the next architectural layer.

9.4 Toward the Agent Vault

The natural evolution of this MVP is the introduction of a dedicated:

🔐 Agent Vault

A secure subsystem responsible for:
• Managing private keys and credentials
• Enforcing access policies
• Mediating all identity-related operations
• Preventing direct exposure of sensitive data to the agent runtime

In this future architecture:
• The agent requests identity operations
• The vault executes them securely
• Midnight validates and proves them privately

9.5 Why This Matters

This MVP is not just a demo — it is a proof of direction.

It shows that:
• Agents can own and manage identity
• Identity can be structured for automation
• Privacy-preserving infrastructure like Midnight is a necessary layer
• A new category of systems — self-sovereign autonomous agents — is emerging

9.6 From Prototype to Ecosystem

This work opens the door to:
• Agent-native identity standards
• Interoperable credential ecosystems
• Autonomous trust frameworks
• Privacy-preserving agent economies

This MVP moves identity from a passive property to an active runtime capability.

PLEASE DO MIND:

⚠️ This is not production-ready
⚠️ It is a research concept and architectural exploration

10. Security Model Shift
This architecture moves from:

❌ Current Model
• Agents = full access + raw secrets
• Trust = implicit
• Privacy = none

✅ Proposed Model
• Agents = constrained actors
• Trust = cryptographic + verifiable
• Privacy = enforced by design

11. Key Insights

Agents are becoming economic actors → They must have identity and accountability
Identity without execution is insufficient → DIDs need runtime orchestration
Selective disclosure is the foundation of agent trust → Not optional, mandatory
Vaults are the new wallets → But for identity + secrets + permissions
Midnight enables what was previously theoretical → Privacy-preserving agent infrastructure

12. Future Research Directions
• Multi-agent trust networks
• Agent-to-agent credential exchange
• Autonomous compliance systems
• Reputation systems for agents
• On-chain governance for agent permissions

13. Conclusion
We are entering a world where:

AI agents act, decide, transact, and represent us.

But without identity and security, this evolution is unstable.

This paper proposes that:

Self-managing DIDs + Selective Disclosure + Secure Vaults + Midnight = A viable path forward

An Agent Identity Infrastructure is needed.

A necessary step toward making autonomous agents trustworthy by design.

The question is no longer whether agents will act autonomously — it is whether they will do so securely.