El lanzamiento en mainnet de Seal MPC por parte de Sui marca un paso concreto hacia dotar a los agentes autónomos de su propia infraestructura de claves descentralizada. El protocolo utiliza Computación Multipartita (MPC) para dividir una clave privada en fragmentos distribuidos en una red de nodos, de modo que un agente de IA pueda firmar transacciones sin reunir la clave completa en un solo lugar. Esto supone un alejamiento significativo de los monederos MPC centralizados que Coinbase y otros han lanzado para agentes, donde el custodio aún posee todos los fragmentos y teóricamente puede reconstruirlos. Pero la arquitectura conlleva un coste de latencia que limita su lugar en la pila del comercio de agentes.
Cómo funciona Seal MPC internamente
Seal MPC opera como una capa en Sui donde un número umbral de nodos debe colaborar para producir una firma. El agente genera un par de claves a través del protocolo, y la clave privada se divide inmediatamente en fragmentos usando un esquema de compartición secreta verificable. Ningún nodo individual ve jamás la clave completa. Cuando el agente necesita firmar una transacción, envía una solicitud a la red, un quórum de nodos ejecuta el protocolo de firma MPC y la firma resultante se devuelve al agente. Este puede entonces enviar la transacción firmada a Sui. La propiedad crítica es que el compromiso de cualquier nodo por debajo del umbral no revela nada sobre la clave. Este es un modelo de seguridad fundamentalmente diferente al de los proveedores MPC de entidad única, donde una brecha en la infraestructura del proveedor puede exponer las claves.
El dilema de latencia que importa para los pagos de agentes
El proceso de firma MPC descentralizada requiere múltiples rondas de comunicación entre nodos. Cada ronda añade latencia de red, y el tiempo total para producir una firma puede oscilar entre varios cientos de milisegundos y unos pocos segundos, dependiendo del umbral y la distribución geográfica de los nodos. Para un agente de IA que paga unos céntimos en USDC para acceder a una API —el tipo de transacción que habilita el protocolo x402 en AWS— ese retraso es inaceptable. Esos pagos necesitan liquidarse en menos de 100 milisegundos para no degradar la experiencia del usuario. Seal MPC no está diseñado para ese caso de uso. Está pensado para acciones donde el agente puede tolerar unos segundos de latencia: desplegar capital, firmar un contrato, actualizar una asignación de tesorería en cadena. La arquitectura prioriza la seguridad sobre la velocidad, lo cual es acertado para decisiones de agentes de alto valor, pero deja el corredor de baja latencia a las soluciones centralizadas.
Dónde encaja Seal MPC en la pila de agentes
El panorama del comercio de agentes se está dividiendo en dos carriles. El primero son los pagos de alta frecuencia y bajo valor —agentes que pagan por llamadas a API, fuentes de datos o computación— donde la velocidad importa más que la descentralización perfecta. Aquí dominan los monederos MPC centralizados y protocolos como x402. El segundo son las acciones asíncronas de alto valor —agentes que gestionan tesorerías, ejecutan acuerdos legales o controlan parámetros de protocolo— donde unos segundos de latencia son irrelevantes y la eliminación de un punto central de fallo es crítica. Seal MPC apunta al segundo carril. Un agente que controla una tesorería de USDC de seis cifras no debería tener sus claves en la infraestructura de un único proveedor. Distribuir esas claves a través de una red MPC descentralizada reduce drásticamente la superficie de ataque.
Preguntas abiertas sobre adopción y componibilidad
Seal MPC es nativo de Sui, lo que significa que los agentes en otras cadenas no pueden usarlo directamente sin un puente o un mecanismo de firma entre cadenas. Eso limita su mercado potencial en un mundo donde los agentes operan en Ethereum, Solana y Base. El protocolo también requiere que los agentes confíen en los operadores de nodos de Seal MPC —no para robar claves, sino para permanecer disponibles. Si demasiados nodos se desconectan, el agente no puede firmar transacciones. La red necesita un conjunto de operadores robusto con altas garantías de tiempo de actividad, y los incentivos para los operadores aún no están del todo claros. Finalmente, está la cuestión de la responsabilidad. Si una firma producida a través de Seal MPC resulta ser maliciosa —por ejemplo, se engañó a un agente para firmar una transacción de drenaje— ¿quién es responsable? La arquitectura descentralizada distribuye el proceso de firma pero también distribuye la culpa, lo que dificulta el recurso.