The InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system.

IPFS

Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.

Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"

Walrus

Move is an executable bytecode language used to implement custom transactions and smart contracts. 

Move



1. Introducción: El comercio mundial es un cuello de botella para la confianza

La cadena de suministro moderna abarca docenas de países, cientos de proveedores e innumerables documentos, muchos de ellos en papel, propensos a errores o no verificables.

Desde el seguimiento de contenedores hasta las declaraciones de aduana y los certificados de origen, el comercio mundial está plagado de:
 • Fragmentación de datos entre jurisdicciones y sistemas
 • Documentación fraudulenta y falsificación
 • Resolución ineficiente de disputas
 • Conciliación costosa y falta de transparencia

Sui ofrece una plataforma de cadena de bloques programable, transparente y escalable capaz de modelar todo el proceso de comercio global, con automatización segura, trazabilidad y gobernanza modular.



2. ¿Por qué utilizar Sui para el comercio y la cadena de suministro?

A diferencia de muchas cadenas de bloques de uso general, la arquitectura orientada a objetos y la ejecución paralela de Sui permiten a las empresas:

Característica y beneficio en las aplicaciones comerciales
Modelado basado en objetos: modele activos del mundo real, como contenedores, envíos y documentos
Escalabilidad horizontal Gestione el seguimiento y las actualizaciones de eventos de gran volumen
Autenticación con ZKLogin Identifique de forma segura a los usuarios (agentes de aduanas, proveedores)
Registro de eventos y emisiones Rastree toda la cadena de custodia en todas las redes
Los módulos Custom Move codifican la lógica de los contratos (por ejemplo, las reglas de origen, las tarifas)

Sui transforma los documentos comerciales en activos digitales verificables y los procesos en flujos de trabajo transparentes y autoejecutables.



3. Caso de uso: envío internacional con certificado de origen

Veamos un caso de uso simplificado.

👟 Escenario: envío de zapatillas desde Vietnam a la UE

Partes interesadas:
 • Fabricante en Ho Chi Minh
 • Transportista
 • Agentes de aduanas
 • Importador de la UE

Flujo de trabajo basado en SUI:
 1. Objeto de envío creado por el fabricante (origen, número de lote, contenido)
 2. Objeto de certificado de origen emitido por la autoridad comercial de Vietnam
 3. La empresa de transporte actualiza TransitStatusObject a medida que avanza el envío
 4. El agente de aduanas verifica los documentos y firma digitalmente el despacho
 5. Un minorista de la UE recibe metadatos verificables sobre el producto y los metadatos en cadena

Ventajas:
 • Todas las partes interesadas tienen acceso a un registro de auditoría a prueba de manipulaciones
 • No se permite compartir documentos por correo electrónico ni falsificar PDF
 • Cumplimiento inmediato de las normas de importación y exportación



4. Arquitectura de un protocolo comercial basado en Sui

Cada activo o documento de la cadena de suministro se convierte en un ciudadano de primera clase de la cadena.

🔩 Módulos principales:
 • ShipmentObject: incluye los artículos, el peso, el origen y la identificación única
 • CertificateModule: verifica la autenticidad del documento y las funciones del emisor
 • Módulo de aprobación de aduanas: los agentes de aduanas pueden aprobar o rechazar el envío
 • TransitEventModule: emite actualizaciones de ubicación (por ejemplo, el puerto se escanea o se carga)

🔐 Ejemplo: mover el módulo para la verificación de certificados

módulo trade: :CertificateModule {
 El certificado de estructura tiene la clave {
 <u8>origin_country: vector,
 emisor: dirección,
 valido_hasta: u64,
 }

 <u8>public fun issue_certificate (emisor: &firmante, país: vector) {
 let cert = Certificado {
 origin_country: país,
 emisor: firmante: :address_of (emisor),
 valid_hasta: 1690000000,
 };
 move_to (emisor, certificado);
 }

 public fun validate (cert: &Certificate): bool {
 timestamp: :now () < cert.valid_until
 }
}

Esta lógica garantiza que solo las autoridades confiables puedan emitir y validar los documentos comerciales.



5. Interoperabilidad: colaboración transfronteriza en tiempo real

La lógica modular de identidad y objetos de Sui permite la cooperación interjurisdiccional sin un control central:

Acción de las partes interesadas sobre Sui
La autoridad portuaria agrega el evento de escaneo a ShipmentObject
La Oficina Nacional de Exportaciones emite un certificado firmado digitalmente
El transportista actualiza la ETA del envío y los informes de estado
El agente de aduanas verifica la autenticidad y el cumplimiento en cadena
El minorista recupera el historial de productos verificable y los metadatos sobre el CO2

Con las API y los paneles de control basados en Sui, incluso los actores no técnicos pueden participar de forma segura en el protocolo.



6. Prevención del fraude y trazabilidad

El fraude comercial mundial se traduce en una pérdida de ingresos de miles de millones de dólares al año. Sui combate esto con:
 • Documentos firmados digitalmente vinculados a la identidad a través de zkLogin
 • Cadena de custodia inmutable con eventos con fecha y hora
 • Tokens de productos basados en NFT con certificaciones vinculadas
 • Activadores inteligentes que evitan la manipulación o las transferencias no autorizadas

Ejemplo: prueba antifalsificación

Cada ficha de producto de lujo (p. ej., un bolso de diseñador) puede:
 • Enlace al certificado de origen y al número de lote de fábrica
 • Incluye un código QR vinculado a un objeto en cadena
 • Impida la reventa a menos que esté autenticado por una cuenta verificada



7. Los créditos de carbono y la integración de los criterios ESG

Las empresas están bajo presión para demostrar que sus cadenas de suministro son sostenibles. Sui puede:
 • Registrar las emisiones de carbono por envío o unidad de producto
 • Permitir a terceros (auditores, ONG) verificar las puntuaciones de carbono
 • Adjunte los informes ESG a los NFT de envío
 • Permitir el comercio en cadena o la reclamación de compensaciones de carbono

Ejemplo: los registros de movimiento de un contenedor marítimo se utilizan para estimar las emisiones y se adjunta un CarbonScoreObject al token del producto. Los compradores pueden verificarlo antes de la compra.



8. Consideraciones de escalamiento para redes globales

La ejecución paralelizada y la baja latencia de Sui hacen que esté lista para la empresa:

Requisitos de escala: Sui & Feature
100.000 actualizaciones diarias Procesamiento paralelo de objetos
Más de 100 partes interesadas por cadena: permisos a nivel de objeto
La API en tiempo real necesita RPC de alto rendimiento y suscripciones a eventos
Retención de datos Historial de objetos y registros en cadena

Sui puede escalar tan rápido como crezca la demanda logística global.



9. Desafíos y estrategias de despliegue

Estrategia de mitigación de desafíos
Restricciones de datos jurisdiccionales Utilice módulos específicos de la región y etiquetas de objeto
Conocimientos limitados sobre la cadena de bloques Cree dApps e interfaces de usuario web fáciles de usar
Integración con sistemas antiguos: middleware y conectores fuera de cadena
Auditoría de seguridad y cumplimiento, registros de emisiones y atestaciones firmadas

Comience con una línea comercial o de productos y, a continuación, amplíe gradualmente los protocolos y las integraciones.



10. Conclusión: construir el futuro del comercio mundial sobre la base del SUI

La arquitectura escalable, programable y centrada en objetos de Sui ofrece la base para un protocolo comercial global y verificable.

Con Sui, las empresas pueden:
 • Reducir el papeleo, las demoras y el fraude
 • Automatice los flujos de trabajo entre múltiples partes
 • Logre una trazabilidad total y el cumplimiento de las normas ESG
 • Cree capas de datos compartidas sin servidores centrales

En un mundo en el que la confianza, la transparencia y la velocidad definen el éxito comercial, Sui es más que una cadena de bloques: es la infraestructura de confianza para las cadenas de suministro del mañana.

⸻

1. Introduction: Global Trade Is a Trust Bottleneck

The modern supply chain spans dozens of countries, hundreds of vendors, and countless documents—many of them paper-based, error-prone, or unverifiable.

From container tracking to customs declarations and certificates of origin, global trade is plagued by:
	•	Data fragmentation across jurisdictions and systems
	•	Fraudulent documentation and counterfeiting
	•	Inefficient dispute resolution
	•	Costly reconciliation and lack of transparency

Sui offers a programmable, transparent, and scalable blockchain platform capable of modeling the entire global trade process—with secure automation, traceability, and modular governance.

⸻

2. Why Use Sui for Trade and Supply Chain?

Unlike many general-purpose blockchains, Sui’s object-oriented architecture and parallel execution allow enterprises to:

Feature	Benefit in Trade Applications
Object-based modeling	Model real-world assets like containers, shipments, docs
Horizontal scalability	Handle high-volume event tracking and updates
zkLogin authentication	Securely identify users (customs agents, suppliers)
Event logging & emissions	Trace the full chain of custody across networks
Custom Move modules	Encode contract logic (e.g., rules of origin, tariffs)

Sui transforms trade documents into verifiable digital assets—and processes into transparent, self-executing workflows.

⸻

3. Use Case: International Shipment with Certificate of Origin

Let’s walk through a simplified use case.

👟 Scenario: Sneaker shipment from Vietnam to the EU

Stakeholders:
	•	Manufacturer in Ho Chi Minh
	•	Freight carrier
	•	Customs brokers
	•	EU importer

Sui-based Workflow:
	1.	ShipmentObject created by manufacturer (origin, batch number, contents)
	2.	CertificateOfOriginObject issued by Vietnam trade authority
	3.	Freight company updates TransitStatusObject as shipment moves
	4.	Customs agent verifies documents and digitally signs clearance
	5.	EU retailer receives verifiable product + metadata on chain

Benefits:
	•	All stakeholders have access to a tamper-proof audit trail
	•	No email-based doc sharing or PDF forgery
	•	Immediate compliance with import/export rules

⸻

4. Architecture of a Sui-Based Trade Protocol

Each supply chain asset or document becomes a first-class citizen on the chain.

🔩 Core Modules:
	•	ShipmentObject – includes items, weight, origin, unique ID
	•	CertificateModule – verifies document authenticity and issuer roles
	•	CustomsApprovalModule – customs agents can approve/reject shipment
	•	TransitEventModule – emits location updates (e.g., port scanned, loaded)

🔐 Example: Move Module for Certificate Verification

module trade::CertificateModule {
    struct Certificate has key {
        origin_country: vector<u8>,
        issuer: address,
        valid_until: u64,
    }

    public fun issue_certificate(issuer: &signer, country: vector<u8>) {
        let cert = Certificate {
            origin_country: country,
            issuer: signer::address_of(issuer),
            valid_until: 1690000000,
        };
        move_to(issuer, cert);
    }

    public fun validate(cert: &Certificate): bool {
        timestamp::now() < cert.valid_until
    }
}

This logic ensures only trusted authorities can issue and validate trade documents.

⸻

5. Interoperability: Real-Time Collaboration Across Borders

Sui’s modular identity and object logic allows cross-jurisdictional cooperation without central control:

Stakeholder	Action on Sui
Port Authority	Appends scan event to ShipmentObject
National Export Office	Issues digitally signed certificate
Freight Carrier	Updates shipment ETA and condition reports
Customs Agent	Verifies authenticity and compliance on-chain
Retailer	Retrieves verifiable product history + CO2 metadata

With APIs and dashboards built on Sui, even non-technical actors can participate securely in the protocol.

⸻

6. Fraud Prevention and Traceability

Global trade fraud results in billions of dollars in lost revenue annually. Sui combats this with:
	•	Digitally signed documents tied to identity via zkLogin
	•	Immutable chain of custody with timestamped events
	•	NFT-based goods tokens with linked certifications
	•	Smart triggers that prevent tampering or unauthorized transfers

Example: Anti-Counterfeit Proof

Each luxury product token (e.g., designer handbag) can:
	•	Link to origin cert + factory batch number
	•	Include QR code tied to on-chain object
	•	Prevent resale unless authenticated by verified account

⸻

7. Carbon Credits and ESG Integration

Enterprises are under pressure to prove sustainable supply chains. Sui can:
	•	Record carbon emissions per shipment or product unit
	•	Allow third parties (auditors, NGOs) to verify carbon scores
	•	Attach ESG reports to shipping NFTs
	•	Enable on-chain trading or claiming of carbon offsets

Example: A shipping container’s movement logs are used to estimate emissions, and a CarbonScoreObject is attached to the product token. Buyers can verify it before purchase.

⸻

8. Scaling Considerations for Global Networks

Sui’s parallelized execution and low latency make it enterprise-ready:

Scale Requirement	Sui Feature
100,000s of daily updates	Parallel object processing
100+ stakeholders per chain	Object-level permissioning
Real-time API needs	High-throughput RPCs + event subscriptions
Data retention	Object history + on-chain logs

Sui can scale as fast as the global logistics demand grows.

⸻

9. Challenges and Deployment Strategies

Challenge	Mitigation Strategy
Jurisdictional data constraints	Use region-specific modules + object tags
Limited blockchain literacy	Build user-friendly dApps + web UIs
Integration with legacy systems	Middleware + off-chain connectors
Security + compliance auditing	Emission logs + signed attestations

Start with one trade lane or product line, then gradually expand protocols and integrations.

⸻

10. Conclusion: Building the Future of Global Trade on Sui

Sui’s object-centric, programmable, and scalable architecture offers the foundation for a global, verifiable trade protocol.

With Sui, enterprises can:
	•	Reduce paperwork, delays, and fraud
	•	Automate multi-party workflows
	•	Achieve full traceability and ESG compliance
	•	Build shared data layers without central servers

In a world where trust, transparency, and speed define trade success, Sui is more than a blockchain—it’s the trust infrastructure for tomorrow’s supply chains.

Sui’s Role in Streamlining Global Trade and Supply Chain Infrastructure

El papel de Sui en la racionalización del comercio mundial y la infraestructura de la cadena de suministro

Basarse en Sui es emocionante: su modelo centrado en objetos abre nuevos patrones de diseño y un paralelismo más rápido. Pero ⚠️ nuevos modelos = nuevos errores. Los errores de propiedad, las filtraciones de depósitos en garantía o el descuido de las claves de administración pueden provocar pérdidas costosas.

En esta guía encontrará una lista de verificación de seguridad paso a paso 📝, además de un práctico ejemplo de mercado para mostrarle cómo evitar los errores más comunes.

✅ 1) La lista de verificación de seguridad de Sui
 1. 🔑 Privilegio mínimo
 • No confíe en una única «clave de administrador» global.
 • Utilice objetos de capacidad para obtener autoridad.
 • Proteja los poderes administrativos críticos con una gobernanza multifirma o en cadena.
 2. ⚖️ Transferencias atómicas en garantía
 • Guarde siempre los activos dentro de objetos de listado específicos.
 • Utilice bloques de transacciones programables (PTB) para realizar permutas atómicas → evite los gastos anticipados y duplicados.
 3. 🛡️ Valide todas las entradas
 • En Move, compruebe las longitudes, los límites y las restricciones de los vectores.
 • Valide la deserialización y rechace los objetos mal formados.
 • Nunca dé por sentado que la entrada es segura solo porque el objeto existe en la cadena.
 4. 🧪 Prueba y difumina agresivamente
 • Escriba pruebas negativas: entradas no válidas, actualizaciones simultáneas, agotamiento del gas.
 • Añada filtros para los flujos de transacciones inesperados.
 • Automatice la CI para detectar las regresiones de forma temprana.
 5. 🔐 Gestión de claves
 • Almacene las claves de administrador en carteras de hardware.
 • Utilice multisig para las acciones de gobierno.
 • Gire las teclas cuando los miembros del equipo se vayan.
 6. 👀 Auditorías e incentivos
 • Haga que se auditen los módulos críticos de Move.
 • Lanza un programa de recompensas por errores para que la comunidad lo pruebe.
 • Recuerda: los ojos externos captan lo que te pierdes.

🏪 2) Ejemplo en la práctica: un mercado seguro

A continuación, se explica cómo aplicar la lista de verificación en una dApp del mercado:
 • Deposita los NFT de forma segura:
El vendedor convierte el NFT en un objeto de anuncio. El contrato de mercado no puede aceptar fondos sin la aprobación del vendedor.
 • Gestione las regalías correctamente:
Calcule las regalías dentro del PTB y asegúrese de que las comisiones se dividan correctamente (¡cuidado con el redondeo!).
 • ¿Reingreso? Aquí no:
El modelo de recursos de Move evita la copia o la reentrada por diseño. Aun así, pruebe todos los flujos para asegurarse de que no haya lagunas lógicas.

📚 Fuentes y lecturas adicionales
 • Sui Docs: Conceptos y transacciones
 • Documento técnico de Sui (modelo centrado en objetos)
 • Documentos del SDK TypeScript de Mysten Labs
 • Mueva un libro
 • En GitHub Repo

✨ Conclusión: En Sui, la seguridad tiene menos que ver con los errores de reentrada al estilo de una máquina virtual y más con la propiedad, la autoridad y la atomización. Si sigues la lista de verificación, reducirás drásticamente la superficie de ataque y, al mismo tiempo, mantendrás seguros los activos de los usuarios.

Building on Sui is exciting — its object-centric model opens up new design patterns and faster parallelism. But ⚠️ new models = new mistakes. Ownership bugs, escrow leaks, or careless admin keys can cause costly losses.

This guide gives you a step-by-step security checklist 📝 plus a practical marketplace example to show how to avoid the most common pitfalls.

✅ 1) The Sui Security Checklist
	1.	🔑 Least Privilege
	•	Don’t rely on a single global “admin key.”
	•	Use capability objects for authority.
	•	Guard critical admin powers with multisig or on-chain governance.
	2.	⚖️ Atomic Escrow Transfers
	•	Always escrow assets inside dedicated Listing objects.
	•	Use Programmable Transaction Blocks (PTBs) for atomic swaps → prevents front-running and double spends.
	3.	🛡️ Validate All Inputs
	•	In Move, check vector lengths, bounds, and constraints.
	•	Validate deserialization and reject malformed objects.
	•	Never assume input safety just because the object exists on-chain.
	4.	🧪 Test & Fuzz Aggressively
	•	Write negative tests: invalid inputs, concurrent updates, gas exhaustion.
	•	Add fuzzing for unexpected transaction flows.
	•	Automate in CI to catch regressions early.
	5.	🔐 Key Management
	•	Store admin keys in hardware wallets.
	•	Use multisig for governance actions.
	•	Rotate keys when team members leave.
	6.	👀 Audits & Incentives
	•	Get critical Move modules audited.
	•	Launch a bug bounty program for community testing.
	•	Remember: external eyes catch what you miss.

🏪 2) Example in Practice: A Safe Marketplace

Here’s how to apply the checklist in a marketplace dApp:
	•	Escrow NFTs safely:
Seller moves the NFT into a Listing object. The marketplace contract cannot take funds without seller’s approval.
	•	Handle royalties correctly:
Compute royalties inside the PTB, ensuring correct fee splitting (watch out for rounding!).
	•	Reentrancy? Not here:
Move’s resource model prevents copying/reentrancy by design. Still, test all flows to ensure no logical loopholes.

📚 Sources & Further Reading
	•	Sui Docs: Concepts & Transactions
	•	Sui Whitepaper (object-centric model)
	•	Mysten Labs TypeScript SDK Docs
	•	Move Book
	•	Sui GitHub Repo

✨ Takeaway: On Sui, security is less about EVM-style reentrancy bugs and more about ownership, authority, and atomicity. If you follow the checklist, you’ll reduce your attack surface dramatically while keeping user assets safe.

🔒 Securing Your Sui App: A Practical Security Checklist

🔒 Proteger su aplicación Sui: una práctica lista de verificación de seguridad

**Empiezas por instalar la CLI de Sui y la cadena de herramientas Move para poder crear y publicar código, luego ejecutas sui client active-address para confirmar que un par de claves funciona y te pones manos a la obra para probar la SUI, después de lo cual creas un nuevo paquete de Move con la plantilla para no luchar contra la estructura de carpetas, luego editas un solo módulo para definir un objeto simple con un campo de propietario y algunos métodos como init, update y transfer para que puedas hacer ejercicio El modelo de objetos de Sui rápidamente, luego compilas con sui, mueves, compilas y corriges cualquier error que muestre el compilador porque ese es tu ciclo de retroalimentación más rápido, luego <value>publicas con sui client publish --gas-budget y tomas los ID del paquete y módulo de la salida para poder llamar a las funciones, luego llamas a tu función de entrada de inicio para acuñar un objeto y copiar el ID del objeto de los efectos de la transacción, luego ejecutas sui client object <id>para ver la versión, el propietario y los campos, de modo que confirmas que la cadena escribió lo que esperabas, si te encuentras con «falta de gas», reduces el presupuesto de gas o solicitas más SUI dado que cada publicación y llamada cuesta gasolina, si aparece «módulo no encontrado», probablemente haya usado el ID de paquete incorrecto o se olvidó de reconstruirlo, si la transferencia falla por un error de capacidad, es probable que hayas compartido el objeto cuando quisiste decir que era propietario o te olvidaste de pasar la forma de argumento correcta, una vez que lo básico funciona, escribes el flujo en un script de shell o JavaScript, de modo que un comando crea, publica, acuña, actualiza y transfiere, lo que ahorra tiempo y evita errores tipográficos, y finalmente envías este ejemplo mínimo a un repositorio para que los compañeros de equipo puedan clonar y ejecutar los mismos pasos en minutos; al tratar el objeto como la unidad de pensamiento en lugar de como un único contrato global, alinea la forma en que codificas con la forma en que Sui almacena el estado, lo que mantiene limpio tu modelo mental y evita las reentradas difíciles de depurar o las carreras estatales globales que podrías encontrar en otras cadenas, y dado que Sui paraleliza las transacciones con objetos propios, también recibes una confirmación rápida mientras iteras, lo que hace que la incorporación sea mucho más agradable.**

**You start by installing the Sui CLI and the Move toolchain so you can build and publish code, then you run sui client active-address to confirm a working keypair and hit the faucet to get test SUI, after which you create a fresh Move package with the template so you don’t fight folder structure, then you edit a single module to define a simple object with an owner field and a few methods like init, update, and transfer so you can exercise Sui’s object model quickly, next you compile with sui move build and fix any errors the compiler shows because that is your fastest feedback loop, then you publish with sui client publish --gas-budget <value> and grab the package and module IDs from the output so you can call functions, after that you call your init entry function to mint an object and copy the object ID from the transaction effects, then you run sui client object <id> to see version, owner and fields so you confirm the chain wrote what you expect, if you run into “insufficient gas” you shrink the gas budget or request more test SUI since every publish and call costs gas, if you get “module not found” you probably used the wrong package ID or forgot to rebuild, if your transfer fails with a capability error you likely made the object shared when you meant owned or you forgot to pass the correct argument shape, once the basics work you script the flow in a shell or JavaScript script so one command builds, publishes, mints, updates and transfers, which saves time and prevents typos, and finally you push this minimal example to a repo so teammates can clone and run the same steps in minutes; by treating the object as the unit of thinking rather than a single global contract you align how you code with how Sui stores state, which keeps your mental model clean and prevents hard-to-debug reentrancy or global-state races that you might meet on other chains, and because Sui parallelizes owned-object transactions you also see fast confirmation while you iterate which makes onboarding much nicer.**

From clean install to your first on-chain object without getting stuck

Desde una instalación limpia hasta tu primer objeto en cadena sin quedarte atascado

R: El sistema de tipos lineales de Move refuerza la seguridad de los recursos en el momento de la compilación, lo que evita el doble gasto, los errores tipo reingreso o la pérdida de activos. Al modelar los tokens, las posiciones y los derechos como recursos (struct <T>has key, store>), los desarrolladores se aseguran de que no puedan duplicarse ni descartarse implícitamente. Además de prevenir el robo, puedes codificar las invariantes específicas de un dominio (por ejemplo, «la garantía siempre debe ser superior a la deuda») directamente y convertirlas en abstracciones seguras. Esto hace innecesarias muchas comprobaciones de tiempo de ejecución, lo que convierte la aplicación en el propio lenguaje.

A: Move’s linear type system enforces resource safety at compile time, preventing double-spending, reentrancy-style bugs, or lost assets. By modeling tokens, positions, and rights as resources (struct<T> has key, store>), developers ensure they cannot be duplicated or implicitly discarded. Beyond preventing theft, you can encode domain-specific invariants (e.g., “collateral must always exceed debt”) directly into type-safe abstractions. This makes many runtime checks unnecessary — shifting enforcement into the language itself.

How can Move’s type system improve security in financial smart contracts?

¿Cómo puede el sistema de tipos de Move mejorar la seguridad en los contratos financieros inteligentes?



1. Introducción: el dilema del intercambio de datos empresariales

Las empresas actuales están más interconectadas que nunca, pero compartir datos de forma segura entre organizaciones sigue siendo uno de los desafíos más difíciles. Ya se trate de cadenas de suministro, redes de seguros o consorcios financieros, las empresas luchan contra:
 • Falta de interoperabilidad de datos
 • Miedo al uso indebido o a la violación de los datos
 • Auditorías redundantes y gastos generales de cumplimiento
 • Canalizaciones de información aisladas y anticuadas

La cadena de bloques, especialmente Sui, ofrece un camino a seguir al permitir un intercambio de datos verificable, modular y autorizado, con una trazabilidad total y una aplicación lógica integradas.



2. ¿Por qué elegir Sui para el intercambio de datos entre empresas?

Sui se destaca por su arquitectura centrada en objetos, su diseño escalable y su compatibilidad con la verificación segura de la identidad.

🔍 Ventajas únicas de Sui:

Función: relevancia para el intercambio de datos
Modelo de datos basado en objetos Cada paquete de datos tiene una identidad, un ciclo de vida y un propietario únicos
Control de acceso mediante Move Control, que puede leer, escribir o modificar los datos compartidos
ZKLogin para identificación empresarial: autentica de forma segura con las credenciales de nube existentes
Registros de auditoría inmutables: trazabilidad total de quién compartió o accedió a los datos
Lógica de contrato modular Personalice los permisos de datos, los esquemas y los activadores




3. Caso de uso en el mundo real: fabricación y logística

Examinemos un escenario en el que varios fabricantes y proveedores de logística necesitan compartir el estado de los envíos, los datos de calidad de la producción y los niveles de inventario, sin comprometer la privacidad ni el control.

Problemas tradicionales:
 • Silos de datos y retrasos en todos los sistemas (por ejemplo, SAP, Oracle)
 • Desconfianza en la precisión de los datos
 • Conciliaciones manuales ineficientes

Solución compatible con Sui:
 • Cada envío se convierte en un objeto Sui con un estado dinámico
 • Los proveedores, la logística y los minoristas tienen permisos específicos
 • Los eventos se emiten en cada etapa: empaquetados, enviados, entregados
 • Todas las partes verifican los estados mediante consultas en cadena o API fuera de cadena

✅ Resultado: visibilidad en tiempo real con un registro de auditoría completo, lo que reduce las disputas y los errores de entrega.



4. Arquitectura: creación de un protocolo interempresarial en Sui

🔧 En cadena:
 • DataObject: encapsula la información compartida (por ejemplo, el identificador de envío, los registros de temperatura, los certificados)
 • AccessControlModule: administra las funciones y los permisos (quién puede escribir, ver o transferir la propiedad)
 • AuditModule: registra los eventos clave, los cambios de estado o las actualizaciones de metadatos

🔒 Ejemplo de fragmento de movimiento:

módulo logístico: :AccessControl {
 El permiso de estructura tiene la clave {
 data_id: ID,
 visor: dirección,
 can_edit: bool,
 }

 public fun grant_view_permission (data_id: ID, espectador: dirección) {
 move_to (&viewer, Permission {data_id, viewer, can_edit: false});
 }

 public fun update_data (datos: &mut SharedData, visor: &Permiso) {
 ¡afirmar! (viewer.can_edit, «El espectador no tiene permiso de escritura»);
 data.status = «Actualizado»;
 }
}




5. Privacidad de datos e identidad de conocimiento cero

No todos los datos deben ser visibles para todos. Sui permite la exposición selectiva de datos a través de:
 • ZKLogin para la autenticación sin revelar la identidad del usuario
 • Cifrado de los campos de objetos almacenados en cadena
 • Indicadores de almacenamiento fuera de la cadena para datos sensibles al RGPD
 • Concesión selectiva de permisos mediante tokens de acceso o credenciales basadas en NFT

Esto garantiza que las empresas puedan colaborar de forma segura y, al mismo tiempo, conservar la privacidad y el control sobre los datos confidenciales.



6. Modelos de gobernanza para protocolos compartidos

Cuando varias organizaciones administran conjuntamente un protocolo, es esencial definir:

Opciones de aspecto con Sui
Acceso basado en roles de gobierno (administrador, lector, editor)
Actualizaciones de contratos: aprobaciones de múltiples firmas o votaciones basadas en DAO
Resolución de disputas: módulos de arbitraje en cadena o lógica de pausas
Reglas de jurisdicción: módulos regionales con contexto legal

Move le permite codificar estas reglas de gobierno en forma de contratos modulares, lo que reduce la ambigüedad y hace cumplir el cumplimiento de forma programática.



7. Estudio de caso: un consorcio de seguros comparte datos de reclamaciones

Escenario: Tres aseguradoras forman un consorcio para reducir el fraude mediante el intercambio de datos sobre reclamaciones.

Problema:
 • Reclamaciones duplicadas en todas las empresas
 • La conciliación manual lleva semanas
 • Obstáculos legales para el intercambio de datos

Solución basada en Sui:
 • El «objeto de reclamación» compartido se creó al enviarlo
 • El módulo AccessControl otorga acceso limitado de lectura/escritura a las aseguradoras asociadas
 • Los eventos y cambios de estado (por ejemplo, aprobados o marcados) se rastrean en cadena
 • Solo se comparten los datos anónimos de las reclamaciones (p. ej., los daños sufridos por el vehículo o la fecha y hora)

Resultados:
 • Reducción del 35% en las solicitudes duplicadas
 • Validación instantánea por parte de los socios
 • Proceso de revisión de reclamaciones totalmente auditable



8. Integración entre cadenas y fuera de la cadena

Los protocolos de intercambio de datos de Sui pueden interactuar con:
 • Sistemas fuera de la cadena que utilizan API, oráculos y puentes de datos seguros
 • Otras cadenas a través del marco de interoperabilidad en evolución de Sui (por ejemplo, LayerZero, Wormhole)

Por ejemplo, una red de energía puede compartir créditos de carbono dentro de la cadena entre Sui y Polygon, al tiempo que conserva los registros de auditoría en el almacenamiento de Sui.



9. Desafíos y estrategias de mitigación

Solución basada en Challenge Sui
Restricciones legales a la transferencia de datos Utilice los módulos compatibles con la jurisdicción de ZKLogin +
La madurez tecnológica variable de los socios crea contenedores y paneles de API para un acceso con poco código
Control de versiones de esquemas compartidos Utilice el control de versiones de objetos y contratos actualizables
Necesidad de una validación fuera de la cadena Combine los oráculos con las pruebas de eventos dentro de la cadena

Sui brinda a las empresas la flexibilidad necesaria para diseñar teniendo en cuenta las restricciones del mundo real, sin comprometer la seguridad o el control.



10. Conclusión: Sui como capa de confianza para la colaboración empresarial

Los datos son el nuevo petróleo, pero solo cuando se comparten, son confiables y son procesables. Con Sui, las empresas pueden:
 • Codificar la lógica de colaboración directamente en los contratos inteligentes
 • Controle quién ve y edita los datos confidenciales
 • Realice un seguimiento, audite y aplique las reglas de protocolo automáticamente
 • Cree canales de datos escalables, seguros y que respeten la privacidad

A medida que más industrias exigen un intercambio de datos programable y que minimice la confianza, Sui proporciona la infraestructura ideal para crear ecosistemas compartidos y a prueba de manipulaciones.

⸻

1. Introduction: The Enterprise Data Sharing Dilemma

Enterprises today are more interconnected than ever, yet securely sharing data between organizations remains one of the toughest challenges. Whether it’s supply chains, insurance networks, or financial consortia, companies struggle with:
	•	Lack of data interoperability
	•	Fear of data misuse or breaches
	•	Redundant audits and compliance overhead
	•	Siloed and outdated information pipelines

Blockchain, especially Sui, offers a path forward by enabling verifiable, modular, and permissioned data exchange—with full traceability and logic enforcement baked in.

⸻

2. Why Sui for Cross-Enterprise Data Sharing?

Sui stands out due to its object-centric architecture, scalable design, and support for secure identity verification.

🔍 Sui’s Unique Advantages:

Feature	Relevance to Data Sharing
Object-based data model	Each data packet has a unique identity, lifecycle, and owner
Access control via Move	Control who can read, write, or modify shared data
zkLogin for enterprise ID	Authenticate with existing cloud credentials securely
Immutable audit logs	Full traceability of who shared or accessed data
Modular contract logic	Tailor data permissions, schemas, and triggers


⸻

3. Real-World Use Case: Manufacturing & Logistics

Let’s examine a scenario where multiple manufacturers and logistics providers need to share shipping status, production quality data, and inventory levels—without compromising privacy or control.

Traditional Problems:
	•	Data silos and delays across systems (e.g., SAP, Oracle)
	•	Mistrust over data accuracy
	•	Inefficient manual reconciliations

Sui-Enabled Solution:
	•	Each shipment becomes a Sui object with a dynamic status
	•	Suppliers, logistics, and retailers have scoped permissions
	•	Events are emitted at every stage: packaged, shipped, delivered
	•	All parties verify states via on-chain queries or off-chain APIs

✅ Result: Real-time visibility with full audit trail, reducing disputes and delivery errors.

⸻

4. Architecture: Building a Cross-Enterprise Protocol on Sui

🔧 On-Chain:
	•	DataObject: encapsulates the shared information (e.g., shipment ID, temperature logs, certs)
	•	AccessControlModule: manages roles and permissions (who can write, view, or transfer ownership)
	•	AuditModule: logs key events, state changes, or metadata updates

🔒 Example Move Snippet:

module logistics::AccessControl {
    struct Permission has key {
        data_id: ID,
        viewer: address,
        can_edit: bool,
    }

    public fun grant_view_permission(data_id: ID, viewer: address) {
        move_to(&viewer, Permission { data_id, viewer, can_edit: false });
    }

    public fun update_data(data: &mut SharedData, viewer: &Permission) {
        assert!(viewer.can_edit, "Viewer lacks write permission");
        data.status = "Updated";
    }
}


⸻

5. Data Privacy and Zero-Knowledge Identity

Not all data should be visible to everyone. Sui enables selective data exposure through:
	•	zkLogin for authentication without revealing user identity
	•	Encryption of object fields stored on-chain
	•	Off-chain storage pointers for GDPR-sensitive data
	•	Selective permission grants using access tokens or NFT-based credentials

This ensures enterprises can collaborate securely while retaining privacy and control over sensitive data.

⸻

6. Governance Models for Shared Protocols

When multiple organizations co-manage a protocol, it’s essential to define:

Aspect	Options with Sui
Access Governance	Role-based access (admin, reader, editor)
Contract Upgrades	Multi-sig approvals or DAO-based voting
Dispute Resolution	On-chain arbitration modules or pause logic
Jurisdiction Rules	Regional modules with legal context

Move allows you to encode these governance rules as modular contracts, reducing ambiguity and enforcing compliance programmatically.

⸻

7. Case Study: Insurance Consortium Sharing Claims Data

Scenario: Three insurers form a consortium to reduce fraud by sharing claims data.

Problem:
	•	Duplicate claims across companies
	•	Manual reconciliation taking weeks
	•	Legal hurdles for data exchange

Sui-Based Solution:
	•	Shared “ClaimObject” created upon submission
	•	AccessControlModule grants limited read/write access to partner insurers
	•	Events and state changes (e.g., approved, flagged) tracked on-chain
	•	Only anonymized claim data (e.g., car damage + timestamp) is shared

Outcomes:
	•	35% drop in duplicate claims
	•	Instant validation by partners
	•	Fully auditable claims review process

⸻

8. Cross-Chain and Off-Chain Integration

Sui data-sharing protocols can interoperate with:
	•	Off-chain systems using APIs, oracles, and secure data bridges
	•	Other chains via Sui’s evolving interoperability framework (e.g., LayerZero, Wormhole)

For example, an energy grid can share on-chain carbon credits across both Sui and Polygon, while preserving audit logs in Sui’s storage.

⸻

9. Challenges and Mitigation Strategies

Challenge	Sui-Based Solution
Legal restrictions on data transfer	Use zkLogin + jurisdiction-aware modules
Varying tech maturity of partners	Build API wrappers and dashboards for low-code access
Versioning of shared schemas	Use object version control and upgradeable contracts
Need for off-chain validation	Combine oracles with on-chain event proofs

Sui gives enterprises flexibility to design around real-world constraints, without compromising security or control.

⸻

10. Conclusion: Sui as the Trust Layer for Enterprise Collaboration

Data is the new oil—but only when shared, trusted, and actionable. With Sui, enterprises can:
	•	Encode collaboration logic directly in smart contracts
	•	Control who sees and edits sensitive data
	•	Track, audit, and enforce protocol rules automatically
	•	Build scalable, secure, and privacy-respecting data pipelines

As more industries demand trust-minimized, programmable data exchange, Sui provides the ideal infrastructure for building shared, tamper-proof ecosystems.

Building Cross-Enterprise Data Sharing Protocols on Sui

Creación de protocolos de intercambio de datos entre empresas en Sui

¿Cuáles son las principales características y funcionalidades de los bots AMM dentro del ecosistema de Sui? ¿Cómo mejoran los mecanismos comerciales tradicionales y qué ventajas ofrecen a los usuarios que utilizan los protocolos DeFi en la red Sui?

¿Necesito construir uno o puedo usar Turbos Finance, por ejemplo

What are the key features and functionalities of AMM bots within the Sui ecosystem? How do they improve upon traditional trading mechanisms, and what advantages do they offer to users engaging with DeFi protocols on the Sui network?

Do I need to build one or I can use Turbos Finance for example

AMM Bot in Sui Ecosystem

AMM Bot en el ecosistema Sui

# 👀 SEAL está disponible en Sui Testnet. Creo que la privacidad de los datos de Web3 está a punto de cambiar

En la Web3, es común escuchar frases como** «los usuarios son dueños de sus datos»** o** «descentralizado por diseño»**. Sin embargo, si se analiza detenidamente, muchas aplicaciones aún dependen de infraestructuras centralizadas para gestionar los datos confidenciales, y utilizan servicios como AWS o Google Cloud para la administración de claves. Esto introduce una contradicción: descentralización en la superficie, centralización en el fondo.


Pero, ¿y si hubiera una forma de gestionar los secretos de forma segura, sin renunciar a la descentralización? Presentamos SEAL: Decentralized Secrets Management (DSM), que ya está disponible en la red de pruebas Sui. SEAL tiene como objetivo corregir una de las mayores hipocresías de Web3: propugnar la descentralización mientras usa AWS en secreto

![](https://ipfs-cdn.peeranha.io/QmcRWFsXzUBecBmZBzVPMdtSS9zqA4yJMysXhPdYhE3bWK)

# Quizás me preguntes: ¿Qué es SEAL?

SEAL es un protocolo que te permite gestionar datos confidenciales de forma segura y**descentralizada**, creado específicamente para el mundo de la Web3. Piense en ello como una capa de control de acceso que prioriza la privacidad y que se conecta a su dApp.



Puede pensar en SEAL como una especie de bloqueo programable para sus datos. Con Move on Sui no solo bloqueas y desbloqueas archivos manualmente, sino que**escribes políticas directamente en tus contratos inteligentes**.

Supongamos que estás creando una dApp en la que:

- Solo los titulares de NFT pueden desbloquear un tutorial premium
- O tal vez un DAO tenga que votar antes de que se revelen los archivos confidenciales
- O quieres que los metadatos estén bloqueados en el tiempo y que solo se pueda acceder a ellos después de una fecha específica

SEAL hace que todo eso sea posible. El control de acceso funciona *en cadena*, es totalmente automatizado, sin necesidad de que un administrador lo gestione. Solo lógica, integrada directamente en la cadena de bloques.

SEAL hace que todo eso sea posible. El control de acceso funciona *en cadena*, es totalmente automatizado, sin necesidad de que un administrador lo gestione. Solo lógica, integrada directamente en la cadena de bloques.

Otra pieza interesante es cómo SEAL maneja el**cifrado**. Utiliza algo llamado**cifrado de umbral**, lo que significa que ningún nodo puede descifrar los datos por sí solo. Se necesita un grupo de servidores para trabajar juntos, algo parecido a la firma múltiple, pero para desbloquear secretos. Esto distribuye la confianza y evita el problema habitual de un único punto de fallo.

Y para mantener la verdadera privacidad, SEAL cifra y descifra todo lo que esté en el lado del cliente**. Tus datos nunca son visibles para ningún backend. Permanecen en tus manos, literalmente, en tu dispositivo.

y a SEAL no le importa dónde guardes tus datos. Ya sea IPFS, Arweave, Walrus o alguna otra plataforma, SEAL no intenta controlar esa parte. Solo se centra en**quién puede ver qué**, no en *dónde* se almacenan las cosas.

> Así que sí, no se trata solo de una biblioteca o API, sino de una**capa que prioriza la cadena, el acceso controlado y la privacidad por defecto**para tu DApp.


![](https://ipfs-cdn.peeranha.io/QmPTLrU3XXDG3zx92LXhh8GzdRgUG98rPb8ZkX42nUf77S)


**SEAL llena un vacío bastante crítico**. Vamos a desglosarlo un poco más. 

---

Si estás creando una dApp que trata**cualquier tipo de datos confidenciales**(contenido cerrado, documentos de usuario, mensajes cifrados e incluso metadatos de NFT bloqueados por tiempo), te encontrarás con el mismo problema:

➡️ ¿Cómo se gestiona el acceso de forma segura, sin depender de un servicio centralizado?

Sin algo como SEAL, la mayoría de los equipos tampoco:

1. Utilice herramientas centralizadas como AWS KMS o Firebase, lo que claramente va en contra de la descentralización
2. O trate de arreglar ellos mismos la lógica de cifrado a medias, que por lo general termina siendo frágil y difícil de auditar

https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22

Ninguno de los dos se ajusta bien. Especialmente cuando intentas crear aplicaciones confiables en múltiples cadenas o comunidades.

**SEAL hace que todo ese proceso sea modular y programable.**

Usted define las reglas de acceso en los contratos inteligentes de Move y SEAL se encarga del resto (generación de claves, aprobación del descifrado y control del acceso), todo ello sin que nadie emita las claves manualmente ni realice comprobaciones de backend.

Y lo que es mejor, esas reglas son**auditables e inmutables**: una vez que están en cadena, se rigen por el contrato, no por un administrador humano.

Así que en lugar de preguntar «¿quién debe gestionar el acceso a estos datos?» solo tienes que preguntar:

> «¿Qué lógica debería definir el acceso?»
> > ... y deja que la cadena se encargue. Limpio y escalable.

Eso es lo que hace que SEAL sea relevante para algo más que «herramientas de seguridad»: es una capa base para cualquier dApp que se preocupe por la privacidad, el cumplimiento o la lógica de acceso dinámico.**

Es un cambio pequeño, pero cambia mucho la forma en que pensamos sobre los datos en la Web3. En lugar de cifrarlos *después* de la implementación o confiar en servicios externos,**se empieza con la privacidad integrada y el acceso se gestiona completamente mediante la lógica de los contratos inteligentes.**

Y eso es exactamente lo que Web3 necesita ahora mismo.

---
# ¿Cómo funciona realmente SEAL?
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

Hemos explicado**qué es SEAL**y**por qué Web3**lo necesita**. Veamos cómo se construye realmente bajo el capó. En esta parte es donde las cosas se vuelven más técnicas, pero en el buen sentido. La arquitectura es elegante una vez que ves cómo encajan todas las piezas.

En un nivel superior, SEAL combina la**lógica de acceso en cadena**con la**gestión de claves fuera de la cadena**, mediante una técnica denominada**Cifrado basado en la identidad (IBE)**. Esto permite a los desarrolladores cifrar los datos *para convertirlos en una identidad* y, luego, confiar en contratos inteligentes para definir *quién puede descifrarlos.

## Paso 1: reglas de acceso en los contratos inteligentes (en Sui)

Todo comienza con el contrato inteligente. Cuando utilizas SEAL, defines una función llamada seal_approve en tu contrato de Move; aquí es donde escribes las condiciones para el descifrado.

Por ejemplo, esta es una sencilla regla de bloqueo temporal escrita en Move:

```rust
entry fun seal_approve(id: vector<u8>, c: &clock::Clock) {
    let mut prepared: BCS = bcs::new(id);
    let t = prepared.peel_u64();
    let leftovers = prepared.into_remainder_bytes();
    assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess);
}
```

Una vez desplegado, este contrato actúa como guardián. Siempre que alguien quiera descifrar datos, su solicitud se comparará con esta lógica. Si se aprueba, la clave se libera. Si no, están bloqueados. Nadie tiene que intervenir.

##**Paso 2: Cifrado basado en la identidad (IBE)**

Aquí es donde ocurre la magia.

En lugar de cifrar los datos de una dirección de monedero específica (como en el caso de PGP o RSA), SEAL utiliza**cadenas de identidad**, lo que significa que los cifras de forma similar a:

- 0 x dirección de monedero
- dao_vote: proposal_xyz
- PKGID_2025_05_01 (una regla basada en la marca de tiempo)
- o incluso game_user_nft_holder

Cuando los datos están cifrados, tienen el siguiente aspecto:

```rust
Encrypt(mpk, identity, message)
```

- mpk = clave pública maestra (conocida por todos)
- identidad = el destinatario definido de forma lógica
- mensaje = los datos reales

Más adelante, si alguien quiere descifrarlos, el servidor de claves comprueba si cumplen con la política (mediante la llamada en cadena seal_approve). Si se aprueba, devuelve una clave privada derivada para esa identidad.

```rust
Derive(msk, identity) → sk  
Decrypt(sk, encrypted_data)
```

A continuación, el usuario puede descifrar el contenido localmente.

Por lo tanto, el cifrado se realiza sin necesidad de saber con antelación *quién* lo descifrará. Solo tiene que definir las *condiciones* y SEAL se encargará del resto más adelante. Es dinámico.


##**Paso 3: El servidor de claves: fuera de la cadena, pero no centralizado**

Quizás te preguntes: ¿quién tiene estas llaves maestras?

Aquí es donde entra en juego el**servidor de clave**de SEAL. Piense en ello como un backend que:

- Contiene la clave secreta maestra (msk)
- Controla los contratos en cadena (como tu lógica seal_approve)
- Solo emite claves derivadas si se cumplen las condiciones

Pero, y esto es clave, SEAL no depende solo de *un servidor* de claves. Puedes ejecutarlo en**modo umbral**, donde varios servidores independientes deben ponerse de acuerdo antes de emitir una clave de descifrado.

Por ejemplo: 3 de cada 5 servidores de claves deben aprobar la solicitud. Esto evita los puntos centrales de falla y también permite la descentralización en la capa de administración de claves.

Aún mejor, en el futuro, SEAL admitirá**MPC (computación multipartita)** y**configuraciones basadas en enclaves**(como TEE), por lo que puede obtener garantías aún más sólidas sin comprometer la usabilidad.

##**Paso 4: Descifrado del lado del cliente**

Una vez que se devuelve la clave al usuario, el descifrado propiamente dicho se lleva a cabo**en su dispositivo**. Esto significa:

- El servidor nunca ve tus datos
- El backend nunca almacena contenido descifrado
- Solo el usuario puede acceder al mensaje final

Es un modelo de privacidad sólido. Incluso si alguien pone en peligro la capa de almacenamiento (IPFS, Arweave, etc.), no podrá leer los datos sin pasar por la lógica de acceso.

Este es el modelo mental rápido:

![](https://ipfs-cdn.peeranha.io/Qmcni3mRP85eLrfcny1ZgDdeQbe3rj9CdD2y6zHvzyZAS3)

Esta estructura facilita la creación de dApps en las que las reglas de acceso no estén codificadas: son dinámicas, auditables y están totalmente integradas en la lógica de la cadena.

##**El equipo detrás de SEAL**

SEAL está dirigido por**Samczsun**, una figura muy conocida en la comunidad de seguridad de cadenas de bloques. Anteriormente fue socio de investigación en Paradigm, y ha auditado múltiples ecosistemas y los ha salvado de grandes vulnerabilidades. Ahora, se dedica a tiempo completo a convertir a SEAL en una pieza central de la infraestructura de privacidad de Web3.

Con su experiencia y credibilidad, SEAL no es solo otra herramienta experimental: es un intento serio de hacer que la privacidad de datos descentralizada sea práctica y escalable.

A medida que SEAL se lanza en la red de pruebas Sui, incorpora un nuevo estándar sobre la forma en que las aplicaciones Web3 pueden gestionar los secretos. Al combinar el control de acceso en cadena, el cifrado de umbrales y la privacidad del lado del cliente, SEAL ofrece una base más confiable para el manejo descentralizado de datos.

Ya sea que estés creando dApps, DAO o juegos descentralizados, SEAL proporciona un potente conjunto de herramientas para reforzar el control de acceso y proteger los datos de los usuarios sin comprometer la descentralización.

Si Web3 quiere avanzar, una infraestructura segura como SEAL no es opcional, es esencial

# 👀SEAL is Live on Sui Testnet – I Think Web3 Data Privacy Is About to Change

In the Web3, it’s common to hear phrases like **“users own their data”** or **“decentralized by design”**. But when you look closely, many applications still rely on centralized infrastructures to handle sensitive data — using services like AWS or Google Cloud for key management. This introduces a contradiction: decentralization on the surface, centralization underneath.


But what if there was a way to manage secrets securely, without giving up decentralization?Introducing SEAL – Decentralized Secrets Management (DSM), now live on the Sui Testnet. SEAL aims to fix one of Web3’s biggest hypocrisies: shouting decentralization while secretly using AWS

![](https://ipfs-cdn.peeranha.io/QmcRWFsXzUBecBmZBzVPMdtSS9zqA4yJMysXhPdYhE3bWK)

# You maybe ask me: What is SEAL?

SEAL is a protocol that lets you manage sensitive data securely and **decentrally** – built specifically for the Web3 world. Think of it as a privacy-first access control layer that plugs into your dApp.



You can think of SEAL as a kind of programmable lock for your data. You don’t just lock and unlock things manually — you **write policies directly into your smart contracts**, using Move on Sui.

Let’s say you’re building a dApp where:

- Only NFT holders can unlock a premium tutorial
- Or maybe a DAO has to vote before sensitive files are revealed
- Or you want metadata to be time-locked and only accessible after a specific date

SEAL makes all of that possible. The access control lives *onchain*, fully automated, no need for an admin to manage it. Just logic, baked right into the blockchain.

SEAL makes all of that possible. The access control lives *onchain*, fully automated, no need for an admin to manage it. Just logic, baked right into the blockchain.

Another interesting piece is how SEAL handles **encryption**. It uses something called **threshold encryption**, which means: no single node can decrypt the data. It takes a group of servers to work together — kinda like multi-sig, but for unlocking secrets. This distributes trust and avoids the usual single-point-of-failure problem.

And to keep things truly private, SEAL encrypts and decrypts everything **on the client side**. Your data is never visible to any backend. It stays in your hands — literally — on your device.

and SEAL doesn’t care where you store your data. Whether it’s IPFS, Arweave, Walrus, or some other platform, SEAL doesn’t try to control that part. It just focuses on **who’s allowed to see what**, not *where* things are stored.

> So yeah, it’s not just a library or API — it’s an **onchain-first, access-controlled, privacy-by-default layer** for your dApp.


![](https://ipfs-cdn.peeranha.io/QmPTLrU3XXDG3zx92LXhh8GzdRgUG98rPb8ZkX42nUf77S)


**SEAL fills a pretty critical gap**. Let’s break that down a bit more. 

---

If you’re building a dApp that deals with **any form of sensitive data** — gated content, user documents, encrypted messages, even time-locked NFT metadata — you’ll run into the same problem:

➡️ How do you manage access securely, without relying on a centralized service?

Without something like SEAL, most teams either:

1. Use centralized tools like AWS KMS or Firebase, which clearly goes against decentralization
2. Or try to patch together half-baked encryption logic themselves, which usually ends up brittle and hard to audit

https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22

Neither of those scales well. Especially not when you’re trying to build trustless apps across multiple chains or communities.

**SEAL makes that entire process modular and programmable.**

You define your access rules in Move smart contracts, and SEAL handles the rest — key generation, decryption approvals, and access enforcement — all without anyone manually issuing keys or running backend checks.

Even better, those rules are **auditable and immutable** — once they’re onchain, they follow the contract, not a human admin.

So instead of asking “who should manage access to this data?” you just ask:

> “What logic should define access?”
> 

> …and let the chain handle it. Clean and scalable.

That’s what makes SEAL relevant for more than just “security tools” — it’s a base layer for **any dApp that cares about privacy, compliance, or dynamic access logic.**

It’s a small shift — but it changes a lot about how we think of data in Web3. Instead of encrypting *after* deployment, or relying on external services, **you start with privacy built-in — and access handled entirely by smart contract logic.**

And that’s exactly what Web3 needs right now.

---
# How Does SEAL Actually Work?
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

We’ve covered **what SEAL is** and **why Web3 needs it**, let’s take a look at how it’s actually built under the hood. This part is where things get more technical — but in a good way. The architecture is elegant once you see how all the pieces fit together.

At a high level, SEAL works by combining **onchain access logic** with **offchain key management**, using a technique called **Identity-Based Encryption (IBE)**. This allows devs to encrypt data *to an identity*, and then rely on smart contracts to define *who is allowed* to decrypt it.

## Step 1: Access Rules in Smart Contracts (on Sui)

Everything starts with the smart contract. When you’re using SEAL, you define a function called seal_approve in your Move contract — this is where you write your conditions for decryption.

For example, here’s a simple time-lock rule written in Move:

```rust
entry fun seal_approve(id: vector<u8>, c: &clock::Clock) {
    let mut prepared: BCS = bcs::new(id);
    let t = prepared.peel_u64();
    let leftovers = prepared.into_remainder_bytes();
    assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess);
}
```

Once deployed, this contract acts as the gatekeeper. Whenever someone wants to decrypt data, their request will get checked against this logic. If it passes, the key gets released. If not, they’re blocked. No one has to intervene.

## **Step 2: Identity-Based Encryption (IBE)**

Here’s where the magic happens.

Instead of encrypting data for a specific wallet address (like with PGP or RSA), SEAL uses **identity strings** — meaning you encrypt to something like:

- 0xwalletaddress
- dao_voted:proposal_xyz
- PkgId_2025_05_01 (a timestamp-based rule)
- or even game_user_nft_holder

When the data is encrypted, it looks like this:

```rust
Encrypt(mpk, identity, message)
```

- mpk = master public key (known to everyone)
- identity = the logic-defined recipient
- message = the actual data

Later, if someone wants to decrypt, the key server checks if they match the policy (via the seal_approve call onchain). If it’s approved, it returns a derived private key for that identity.

```rust
Derive(msk, identity) → sk  
Decrypt(sk, encrypted_data)
```

The user can then decrypt the content locally.

So encryption is done without needing to know *who* will decrypt ahead of time. You just define the *conditions*, and SEAL figures out the rest later. It’s dynamic.


## **Step 3: The Key Server – Offchain, But Not Centralized**

You might wonder: who’s holding these master keys?

This is where SEAL’s **Key Server** comes in. Think of it as a backend that:

- Holds the master secret key (msk)
- Watches onchain contracts (like your seal_approve logic)
- Only issues derived keys if the conditions are satisfied

But — and this is key — SEAL doesn’t rely on just *one* key server. You can run it in **threshold mode**, where multiple independent servers need to agree before a decryption key is issued.

For example: 3-of-5 key servers must approve the request. This avoids central points of failure and allows decentralization at the key management layer too.

Even better, in the future SEAL will support **MPC (multi-party computation)** and **enclave-based setups** (like TEE) — so you can get even stronger guarantees without compromising usability.

## **Step 4: Client-Side Decryption**

Once the key is returned to the user, the actual decryption happens **on their device**. This means:

- The server never sees your data
- The backend never stores decrypted content
- Only the user can access the final message

It’s a solid privacy model. Even if someone compromises the storage layer (IPFS, Arweave, etc.), they still can’t read the data without passing the access logic.

Here’s the quick mental model:

![](https://ipfs-cdn.peeranha.io/Qmcni3mRP85eLrfcny1ZgDdeQbe3rj9CdD2y6zHvzyZAS3)

This structure makes it easy to build dApps where access rules aren’t hardcoded — they’re dynamic, auditable, and fully integrated into your chain logic.

## **The Team Behind SEAL**

SEAL is led by **Samczsun**, a well-known figure in the blockchain security community. Formerly a Research Partner at Paradigm, he has audited and saved multiple ecosystems from major exploits. Now, he’s focused full-time on building SEAL into a core piece of Web3’s privacy infrastructure.

With his background and credibility, SEAL is not just another experimental tool — it’s a serious attempt at making decentralized data privacy both practical and scalable.

As SEAL goes live on the Sui Testnet, it brings a new standard for how Web3 applications can manage secrets. By combining onchain access control, threshold encryption, and client-side privacy, SEAL offers a more trustworthy foundation for decentralized data handling.

Whether you’re building dApps, DAOs, or decentralized games — SEAL provides a powerful toolkit to enforce access control and protect user data without compromising on decentralization.

If Web3 is going to move forward, secure infrastructure like SEAL is not optional — it’s essential

👀 SEAL- I Think Web3 Data Privacy Is About to Change

👀 SEAL: creo que la privacidad de los datos de Web3 está a punto de cambiar

*Estoy intentando entender este aspecto de la red Sui porque estoy creando, depurando o implementando algo relacionado con esta área. Quiero una explicación detallada de cómo funciona este mecanismo o función, junto con el uso relevante de la CLI, la estructura del código de Move o los conceptos arquitectónicos. Mi objetivo es obtener la suficiente claridad para aplicar este conocimiento en un proyecto real, ya sea un contrato inteligente personalizado, un sistema NFT, una integración de monederos o una herramienta DeFi. La red Sui tiene características únicas en comparación con las cadenas de EVM, por lo que me interesa especialmente saber qué la diferencia y cómo afecta eso a las mejores prácticas de desarrollo. Sería útil tener un código de ejemplo, ejemplos de líneas de comandos o errores típicos a los que prestar atención, especialmente cuando se utiliza la CLI o el SDK de Sui o se implementa en localnet/testnet. En última instancia, quiero evitar errores comunes, seguir los mejores principios de seguridad y asegurarme de que la funcionalidad en la que estoy trabajando se comporte como se espera en condiciones realistas. *

*I'm trying to understand this aspect of the Sui Network because I'm either building, debugging, or deploying something that touches this area. I want a detailed explanation of how this mechanism or feature works, along with relevant CLI usage, Move code structure, or architectural concepts. My goal is to gain enough clarity to apply this knowledge in a real project—whether that's a custom smart contract, an NFT system, a wallet integration, or a DeFi tool. The Sui Network has unique features compared to EVM chains, so I'm particularly interested in what sets it apart and how that affects development best practices. It would help to have sample code, command line examples, or typical errors to watch for, especially when using the Sui CLI, SDK, or deploying on localnet/testnet. Ultimately, I want to avoid common mistakes, follow the best security principles, and ensure that the functionality I’m working on behaves as expected under realistic conditions.*

How do I merge two coin object in Move?

¿Cómo combino dos objetos de monedas en Move?

Intento entender este aspecto de la red Sui porque estoy creando, depurando o implementando algo que toca esta área. Quiero una explicación detallada de cómo funciona este mecanismo o función, junto con el uso relevante de la CLI, la estructura del código de Move o los conceptos arquitectónicos. Mi objetivo es obtener la suficiente claridad para aplicar este conocimiento en un proyecto real, ya sea un contrato inteligente personalizado, un sistema NFT, una integración de monederos o una herramienta DeFi. La red Sui tiene características únicas en comparación con las cadenas de EVM, por lo que me interesa especialmente saber qué la diferencia y cómo afecta eso a las mejores prácticas de desarrollo. Sería útil tener un código de ejemplo, ejemplos de líneas de comandos o errores típicos a los que prestar atención, especialmente cuando se utiliza la CLI o el SDK de Sui o se implementa en localnet/testnet. En última instancia, quiero evitar errores comunes, seguir los mejores principios de seguridad y asegurarme de que la funcionalidad en la que estoy trabajando se comporte como se espera en condiciones realistas.

I'm trying to understand this aspect of the Sui Network because I'm either building, debugging, or deploying something that touches this area. I want a detailed explanation of how this mechanism or feature works, along with relevant CLI usage, Move code structure, or architectural concepts. My goal is to gain enough clarity to apply this knowledge in a real project—whether that's a custom smart contract, an NFT system, a wallet integration, or a DeFi tool. The Sui Network has unique features compared to EVM chains, so I'm particularly interested in what sets it apart and how that affects development best practices. It would help to have sample code, command line examples, or typical errors to watch for, especially when using the Sui CLI, SDK, or deploying on localnet/testnet. Ultimately, I want to avoid common mistakes, follow the best security principles, and ensure that the functionality I’m working on behaves as expected under realistic conditions.

Sin respuesta

Comparte tus conocimientos y experiencia.

Publicaciones

Gana tu parte de 1000 Sui