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. Introduction : Le commerce mondial est un goulot d'étranglement en matière de confiance

La chaîne d'approvisionnement moderne couvre des dizaines de pays, des centaines de fournisseurs et d'innombrables documents, dont beaucoup sont papier, sujets aux erreurs ou invérifiables.

Du suivi des conteneurs aux déclarations douanières et aux certificats d'origine, le commerce mondial est entravé par :
 • Fragmentation des données entre les juridictions et les systèmes
 • Documentation frauduleuse et contrefaçon
 • Résolution des litiges inefficace
 • Conciliation coûteuse et manque de transparence

Sui propose une plateforme blockchain programmable, transparente et évolutive capable de modéliser l'ensemble du processus commercial mondial, avec une automatisation sécurisée, une traçabilité et une gouvernance modulaire.



2. Pourquoi utiliser Sui pour le commerce et la chaîne d'approvisionnement ?

Contrairement à de nombreuses blockchains à usage général, l'architecture orientée objet et l'exécution parallèle de Sui permettent aux entreprises de :

Avantage des fonctionnalités dans les applications commerciales
Modélisation basée sur les objets Modélisez des actifs du monde réel tels que des conteneurs, des envois, des documents
Évolutivité horizontale Gérez le suivi et les mises à jour des événements à volume élevé
Authentification ZKLogin Identifiez en toute sécurité les utilisateurs (agents des douanes, fournisseurs)
Enregistrement des événements et émissions Suivez l'intégralité de la chaîne de contrôle sur les réseaux
Les modules Custom Move encodent la logique des contrats (par exemple, règles d'origine, tarifs)

Sui transforme les documents commerciaux en actifs numériques vérifiables, et les processus en flux de travail transparents et auto-exécutables.



3. Cas d'utilisation : envoi international avec certificat d'origine

Passons en revue un cas d'utilisation simplifié.

👟 Scénario : expédition de baskets du Vietnam vers l'UE

Parties prenantes :
 • Fabricant à Ho Chi Minh
 • Transporteur de marchandises
 • Courtiers en douane
 • Importateur de l'UE

Flux de travail basé sur l'interface utilisateur :
 1. ShipmentObject créé par le fabricant (origine, numéro de lot, contenu)
 2. Certificat d'origine de l'objet délivré par l'autorité commerciale du Vietnam
 3. La compagnie de fret met à jour TransitStatusObject au fur et à mesure que l'expédition est
 4. L'agent des douanes vérifie les documents et signe numériquement le dédouanement
 5. Un détaillant de l'UE reçoit un produit vérifiable et des métadonnées sur la chaîne

Avantages :
 • Toutes les parties prenantes ont accès à une piste d'audit infalsifiable
 • Pas de partage de documents par e-mail ni de falsification de PDF
 • Conformité immédiate aux règles d'import/export



4. Architecture d'un protocole commercial basé sur Sui

Chaque actif ou document de la chaîne d'approvisionnement devient un citoyen de premier ordre sur la chaîne.

🔩 Modules de base :
 • ShipmentObject : inclut les articles, le poids, l'origine et un identifiant unique
 • CertificateModule : vérifie l'authenticité des documents et les rôles des émetteurs
 • Module d'approbation des douanes : les agents des douanes peuvent approuver/rejeter l'expédition
 • TransitEventModule : émet des mises à jour de localisation (par exemple, port scanné, chargé)

🔐 Exemple : module de déplacement pour la vérification des certificats

module trade : :CertificateModule {
 struct Le certificat a une clé {
 <u8>pays_origine : vecteur,
 émetteur : adresse,
 valide_jusqu'à : u64,
 }

 <u8>public fun issue_certificate (émetteur : &signataire, pays : vecteur) {
 let cert = Certificat {
 pays_origine : pays,
 émetteur : signer : :address_of (émetteur),
 valide_jusqu'à : 1690000000,
 } ;
 move_to (émetteur, certificat) ;
 }

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

Cette logique garantit que seules les autorités de confiance peuvent émettre et valider des documents commerciaux.



5. Interopérabilité : collaboration transfrontalière en temps réel

La logique modulaire d'identité et d'objet de Sui permet une coopération interjuridictionnelle sans contrôle central :

Action des parties prenantes concernant Sui
L'autorité portuaire ajoute un événement de numérisation à ShipmentObject
L'Office national des exportations émet un certificat signé numériquement
Le transporteur met à jour l'ETA des expéditions et les rapports de condition
L'agent des douanes vérifie l'authenticité et la conformité en chaîne
Le détaillant récupère un historique vérifiable des produits et des métadonnées sur le CO2

Grâce aux API et aux tableaux de bord basés sur Sui, même les acteurs non techniques peuvent participer au protocole en toute sécurité.



6. Prévention des fraudes et traçabilité

La fraude commerciale mondiale entraîne des milliards de dollars de pertes de revenus chaque année. Sui combat cela avec :
 • Documents signés numériquement liés à l'identité via ZKLogin
 • Chaîne de traçabilité immuable avec événements horodatés
 • Jetons de marchandises basés sur le NFT avec certifications associées
 • Déclencheurs intelligents qui empêchent la falsification ou les transferts non autorisés

Exemple : preuve anti-contrefaçon

Chaque jeton de produit de luxe (par exemple, un sac à main de créateur) peut :
 • Lien vers le certificat d'origine + le numéro de lot d'usine
 • Inclure un code QR lié à un objet en chaîne
 • Empêcher la revente à moins d'être authentifié par un compte vérifié



7. Crédits de carbone et intégration des critères ESG

Les entreprises sont soumises à des pressions pour prouver la durabilité de leurs chaînes d'approvisionnement. Sui peut :
 • Émissions de carbone records par expédition ou unité de produit
 • Permettre à des tiers (auditeurs, ONG) de vérifier les scores carbone
 • Joignez des rapports ESG à l'expédition de NFT
 • Permettre le commerce en chaîne ou la réclamation de compensations de carbone

Exemple : les journaux de mouvements d'un conteneur d'expédition sont utilisés pour estimer les émissions, et un CarbonScoreObject est attaché au jeton du produit. Les acheteurs peuvent le vérifier avant d'acheter.



8. Considérations relatives à l'évolutivité des réseaux mondiaux

L'exécution parallélisée et la faible latence de Sui le rendent prêt à être utilisé en entreprise :

Scale Requirement Sui Feature
100 000 mises à jour quotidiennes Traitement parallèle des objets
Plus de 100 parties prenantes par chaîne Autorisations au niveau de l'objet
L'API en temps réel nécessite des RPC à haut débit et des abonnements à des événements
Conservation des données Historique des objets + journaux en chaîne

Sui peut évoluer aussi rapidement que la demande logistique mondiale augmente.



9. Défis et stratégies de déploiement

Stratégie d'atténuation des défis
Contraintes relatives aux données juridictionnelles Utiliser des modules spécifiques à la région + des balises d'objet
Connaissances limitées en matière de blockchain Créez des applications DApps et des interfaces utilisateur Web conviviales
Intégration avec les systèmes existants Middleware + connecteurs hors chaîne
Audit de sécurité + conformité Journaux d'émissions + attestations signées

Commencez par une voie commerciale ou une gamme de produits, puis étendez progressivement les protocoles et les intégrations.



10. Conclusion : Construire l'avenir du commerce mondial sur Sui

L'architecture programmable et évolutive centrée sur les objets de Sui constitue la base d'un protocole commercial mondial et vérifiable.

Avec Sui, les entreprises peuvent :
 • Réduisez les formalités administratives, les retards et les fraudes
 • Automatisez les flux de travail multipartites
 • Bénéficiez d'une traçabilité complète et d'une conformité ESG
 • Créez des couches de données partagées sans serveurs centraux

Dans un monde où la confiance, la transparence et la rapidité définissent le succès commercial, Sui est bien plus qu'une blockchain, c'est l'infrastructure de confiance pour les chaînes d'approvisionnement de demain.

⸻

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

Le rôle de Sui dans la rationalisation du commerce mondial et de l'infrastructure de la chaîne d'approvisionnement

S'appuyer sur Sui est passionnant : son modèle centré sur l'objet ouvre la voie à de nouveaux modèles de conception et à un parallélisme plus rapide. Mais ⚠️ nouveaux modèles = nouvelles erreurs. Les bugs de propriété, les fuites d'entiercement ou la négligence des clés d'administration peuvent entraîner des pertes coûteuses.

Ce guide vous propose une liste de contrôle de sécurité étape par étape 📝 ainsi qu'un exemple pratique de marketplace pour vous montrer comment éviter les pièges les plus courants.

✅ 1) La liste de contrôle de sécurité Sui
 1. 🔑 Le moindre privilège
 • Ne vous fiez pas à une seule « clé d'administration » globale.
 • Utilisez des objets de capacité pour obtenir de l'autorité.
 • Protégez les pouvoirs administratifs critiques grâce à une gouvernance multisignature ou en chaîne.
 2. ⚖️ Transferts séquestres atomiques
 • Sécurisez toujours les actifs dans des objets de liste dédiés.
 • Utilisez des blocs de transactions programmables (PTB) pour les échanges atomiques → évitez les dépenses anticipées et les doubles dépenses.
 3. 🛡️ Validez toutes les entrées
 • Dans Move, vérifiez les longueurs, les limites et les contraintes des vecteurs.
 • Validez la désérialisation et rejetez les objets mal formés.
 • Ne présumez jamais la sécurité des entrées simplement parce que l'objet existe sur la chaîne.
 4. 🧪 Testez et fuzz de manière agressive
 • Rédigez des tests négatifs : entrées non valides, mises à jour simultanées, épuisement des gaz.
 • Ajoutez du fuzzing pour les flux de transactions inattendus.
 • Automatisez dans CI pour détecter les régressions à un stade précoce.
 5. 🔐 Gestion des clés
 • Stockez les clés d'administration dans des portefeuilles matériels.
 • Utilisez le multisig pour les actions de gouvernance.
 • Faites pivoter les touches lorsque les membres de l'équipe partent.
 6. 👀 Audits et mesures incitatives
 • Faites auditer les modules Move critiques.
 • Lancez un programme Bug Bounty à des fins de test communautaire.
 • N'oubliez pas : les yeux extérieurs détectent ce qui vous manque.

🏪 2) Exemple pratique : un marché sûr

Voici comment appliquer la liste de contrôle dans une DApp de la place de marché :
 • Sécurisez les NFT en toute sécurité :
Le vendeur déplace le NFT vers un objet d'annonce. Le contrat de la place de marché ne peut pas accepter de fonds sans l'approbation du vendeur.
 • Gérez correctement les redevances :
Calculez les redevances dans le PTB, en veillant à une répartition correcte des frais (attention aux arrondis !).
 • Réentrée ? Pas ici :
Le modèle de ressources de Move empêche la copie/la réentrée dès sa conception. Testez tout de même tous les flux pour vous assurer qu'il n'y a aucune faille logique.

📚 Sources et lectures complémentaires
 • Sui Docs : concepts et transactions
 • Livre blanc Sui (modèle centré sur l'objet)
 • Documentation sur le SDK TypeScript de Mysten Labs
 • Carnet de films
 • Sur GitHub Repo

✨ À retenir : sur Sui, la sécurité est moins une question de bogues de réentrée de type EVM qu'une question de propriété, d'autorité et d'atomicité. Si vous suivez la liste de contrôle, vous réduirez considérablement votre surface d'attaque tout en protégeant les actifs des utilisateurs.

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

🔒 Sécurisation de votre application Sui : une liste de contrôle de sécurité pratique

**Vous commencez par installer la CLI Sui et la chaîne d'outils Move pour créer et publier du code, puis vous exécutez sui client active-address pour confirmer qu'une paire de touches fonctionne et vous appuyez sur le robinet pour tester SUI, puis vous créez un nouveau package Move avec le modèle pour ne pas vous opposer à la structure des dossiers, puis vous modifiez un seul module pour définir un objet simple avec un champ propriétaire et quelques méthodes telles que init, update et transfer afin de pouvoir exercer Modélisez rapidement les objets de Sui, puis vous compilez avec sui move build et corrigez toutes les erreurs affichées par le compilateur car c'est votre boucle de feedback la plus rapide, puis vous publiez avec sui client publish --gas-budget <value>et vous récupérez les ID de package et de module depuis la sortie pour pouvoir appeler des fonctions, puis vous appelez votre fonction d'entrée d'initialisation pour créer un objet et copiez l'ID de l'objet depuis les effets de la transaction, puis vous exécutez sui client object <id>pour voir la version, le propriétaire et les champs afin de confirmer que la chaîne a écrit ce que vous attendez, si vous rencontrez un « gaz insuffisant », vous réduisez le budget de gaz ou demandez plus de tests SUI depuis chaque publication et chaque appel coûtent de l'essence, si vous obtenez « module introuvable », vous avez probablement utilisé le mauvais identifiant de package ou si vous avez oublié de reconstruire, si votre transfert échoue en raison d'une erreur de capacité, vous avez probablement partagé l'objet alors que vous vouliez dire possédé ou vous avez oublié de transmettre la forme d'argument correcte. Une fois les bases fonctionnent, vous scriptez le flux dans un shell ou un script JavaScript afin qu'une commande crée, publie, crée, mette à jour et transfère, ce qui permet de gagner du temps et d'éviter les fautes de frappe. Enfin, vous envoyez cet exemple minimal à un dépôt afin que vos coéquipiers puissent cloner et exécuter les mêmes étapes en quelques minutes ; en traitant l'objet comme une unité de pensée plutôt que comme un contrat global unique, vous alignez votre façon de coder avec la façon dont Sui stocke l'état, ce qui permet de garder votre modèle mental propre et d'éviter les réinscriptions difficiles à déboguer ou les courses à l'État mondial que vous pourriez rencontrer sur d'autres chaînes, et comme Sui parallélise les transactions d'objets personnels, vous en voyez également une confirmation rapide au fur et à mesure que vous itérez, ce qui rend l'intégration encore plus agréable.**

**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

De l'installation propre à votre premier objet connecté à la chaîne sans rester bloqué

R : Le système de type linéaire de Move garantit la sécurité des ressources au moment de la compilation, évitant ainsi les doubles dépenses, les bogues liés à la réentrée ou la perte d'actifs. En modélisant les jetons, les positions et les droits comme des ressources (struct <T>has key, store>), les développeurs s'assurent qu'ils ne peuvent pas être dupliqués ou implicitement supprimés. Au-delà de la prévention du vol, vous pouvez coder des invariants spécifiques à un domaine (par exemple, « la garantie doit toujours dépasser la dette ») directement dans des abstractions de type sécurisé. Cela rend de nombreuses vérifications d'exécution inutiles, transférant ainsi l'application au langage lui-même.

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?

Comment le système de types de Move peut-il améliorer la sécurité des contrats financiers intelligents ?



1. Introduction : Le dilemme du partage des données d'entreprise

Les entreprises sont aujourd'hui plus interconnectées que jamais, mais le partage sécurisé des données entre les organisations reste l'un des défis les plus difficiles. Qu'il s'agisse de chaînes d'approvisionnement, de réseaux d'assurance ou de consortiums financiers, les entreprises rencontrent des difficultés avec :
 • Manque d'interopérabilité des données
 • Crainte d'une utilisation abusive ou d'une violation des données
 • Audits redondants et frais de conformité
 • Canalisations d'informations cloisonnées et obsolètes

La blockchain, en particulier Sui, offre une voie à suivre en permettant un échange de données vérifiable, modulaire et autorisé, avec une traçabilité complète et une application logique intégrées.



2. Pourquoi Sui pour le partage de données entre entreprises ?

Sui se distingue par son architecture centrée sur les objets, sa conception évolutive et sa prise en charge de la vérification d'identité sécurisée.

🔍 Les avantages uniques de Sui :

Pertinence des fonctionnalités pour le partage de données
Modèle de données basé sur les objets Chaque paquet de données possède une identité, un cycle de vie et un propriétaire uniques
Contrôle d'accès via Move Control qui peut lire, écrire ou modifier les données partagées
ZKLogin pour Enterprise ID Authentifiez-vous en toute sécurité avec les informations d'identification cloud existantes
Journaux d'audit immuables Traçabilité complète des personnes qui ont partagé ou accédé aux données
Logique contractuelle modulaire Personnalisez les autorisations de données, les schémas et les déclencheurs




3. Cas d'utilisation réel : fabrication et logistique

Examinons un scénario dans lequel plusieurs fabricants et fournisseurs de services logistiques doivent partager l'état des expéditions, les données relatives à la qualité de la production et les niveaux de stocks, sans compromettre la confidentialité ni le contrôle.

Problèmes classiques :
 • Silos de données et retards entre les systèmes (par exemple, SAP, Oracle)
 • Méfiance quant à l'exactitude des données
 • Rapprochements manuels inefficaces

Solution compatible Sui :
 • Chaque envoi devient un objet Sui doté d'un statut dynamique
 • Les fournisseurs, la logistique et les détaillants ont des autorisations limitées
 • Des événements sont émis à chaque étape : emballés, expédiés, livrés
 • Toutes les parties vérifient les états via des requêtes en chaîne ou des API hors chaîne

✅ Résultat : visibilité en temps réel avec piste d'audit complète, réduisant ainsi les litiges et les erreurs de livraison.



4. Architecture : création d'un protocole interentreprises sur Sui

🔧 En chaîne :
 • DataObject : encapsule les informations partagées (par exemple, numéro d'expédition, journaux de température, certificats)
 • AccessControlModule : gère les rôles et les autorisations (qui peut écrire, afficher ou transférer la propriété)
 • AuditModule : enregistre les événements clés, les changements d'état ou les mises à jour des métadonnées

🔒 Exemple d'extrait de mouvement :

module logistics : :AccessControl {
 struct L'autorisation a une clé {
 data_id : ID,
 afficheur : adresse,
 can_edit : bool,
 }

 public fun grant_view_permission (data_id : ID, afficheur : adresse) {
 move_to (&viewer, Autorisation {data_id, viewer, can_edit : false}) ;
 }

 public fun update_data (données : &mut SharedData, afficheur : &Permission) {
 affirmez ! (viewer.can_edit, « L'utilisateur n'a pas le droit d'écrire ») ;
 data.status = « Mis à jour » ;
 }
}




5. Confidentialité des données et identité à connaissance nulle

Toutes les données ne doivent pas être visibles par tous. Sui permet une exposition sélective des données grâce à :
 • ZKLogin pour l'authentification sans révéler l'identité de l'utilisateur
 • Chiffrement des champs d'objets stockés en chaîne
 • Pointeurs de stockage hors chaîne pour les données sensibles au RGPD
 • Octroi d'autorisations sélectives à l'aide de jetons d'accès ou d'informations d'identification basées sur NFT

Les entreprises peuvent ainsi collaborer en toute sécurité tout en préservant la confidentialité et le contrôle des données sensibles.



6. Modèles de gouvernance pour les protocoles partagés

Lorsque plusieurs organisations gèrent conjointement un protocole, il est essentiel de définir :

Options d'aspect avec Sui
Gouvernance des accès Accès basé sur les rôles (administrateur, lecteur, éditeur)
Mises à niveau des contrats : approbations multisignées ou vote basé sur la DAO
Résolution des litiges Modules d'arbitrage en chaîne ou logique de pause
Règles de compétence Modules régionaux avec contexte juridique

Move vous permet d'encoder ces règles de gouvernance sous forme de contrats modulaires, réduisant ainsi l'ambiguïté et garantissant la conformité par programmation.



7. Étude de cas : un consortium d'assurance partage des données relatives aux sinistres

Scénario : Trois assureurs forment un consortium pour réduire la fraude en partageant les données relatives aux sinistres.

Problème :
 • Réclamations dupliquées entre les entreprises
 • Le rapprochement manuel prend des semaines
 • Obstacles juridiques à l'échange de données

Solution basée sur Sui :
 • « ClaimObject » partagé créé lors de la soumission
 • AccessControlModule accorde un accès limité en lecture/écriture aux assureurs partenaires
 • Les événements et les changements d'état (par exemple, approuvés, signalés) sont suivis en chaîne
 • Seules les données de réclamation anonymisées (par exemple, dommages causés à la voiture + horodatage) sont partagées

Résultats :
 • Diminution de 35 % des demandes en double
 • Validation instantanée par les partenaires
 • Processus d'examen des réclamations entièrement vérifiable



8. Intégration inter-chaînes et hors chaîne

Les protocoles de partage de données Sui peuvent interagir avec :
 • Systèmes hors chaîne utilisant des API, des oracles et des ponts de données sécurisés
 • Autres chaînes via le cadre d'interopérabilité évolutif de Sui (par exemple, LayerZero, Wormhole)

Par exemple, un réseau énergétique peut partager des crédits de carbone en chaîne entre Sui et Polygon, tout en préservant les journaux d'audit dans le stockage de Sui.



9. Défis et stratégies d'atténuation

Solution basée sur Challenge Sui
Restrictions légales sur le transfert de données Utiliser ZKLogin + modules tenant compte des juridictions
Maturité technologique variable des partenaires Créez des wrappers d'API et des tableaux de bord pour un accès low-code
Versionnage des schémas partagés Utilisez le contrôle de version des objets et des contrats évolutifs
Nécessité d'une validation hors chaîne Combinez des oracles avec des preuves d'événements en chaîne

Sui offre aux entreprises la flexibilité nécessaire pour concevoir en fonction des contraintes du monde réel, sans compromettre la sécurité ou le contrôle.



10. Conclusion : Sui en tant que couche de confiance pour la collaboration d'entreprise

Les données sont le nouveau pétrole, mais uniquement lorsqu'elles sont partagées, fiables et exploitables. Avec Sui, les entreprises peuvent :
 • Encodez la logique de collaboration directement dans les contrats intelligents
 • Contrôlez qui voit et modifie les données sensibles
 • Suivez, auditez et appliquez automatiquement les règles du protocole
 • Créez des pipelines de données évolutifs, sécurisés et respectueux de la confidentialité

Alors que de plus en plus d'industries exigent un échange de données programmable et minimisé en termes de confiance, Sui fournit l'infrastructure idéale pour créer des écosystèmes partagés et infalsifiables.

⸻

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

Création de protocoles de partage de données interentreprises sur Sui

Quelles sont les principales caractéristiques et fonctionnalités des robots AMM au sein de l'écosystème Sui ? Comment améliorent-ils les mécanismes de trading traditionnels et quels avantages offrent-ils aux utilisateurs utilisant les protocoles DeFi sur le réseau Sui ?

Dois-je en construire un ou je peux utiliser Turbos Finance par exemple

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

Bot AMM dans l'écosystème Sui

# 👀 SEAL est en ligne sur Sui Testnet — Je pense que la confidentialité des données Web3 est sur le point de changer

Dans le Web3, il est courant d'entendre des phrases telles que** « les utilisateurs sont propriétaires de leurs données »** ou** « décentralisé par conception »**. Mais à y regarder de plus près, de nombreuses applications s'appuient toujours sur des infrastructures centralisées pour gérer les données sensibles, en utilisant des services tels qu'AWS ou Google Cloud pour la gestion des clés. Cela introduit une contradiction : la décentralisation en surface, la centralisation en dessous.


Et s'il existait un moyen de gérer les secrets en toute sécurité, sans renoncer à la décentralisation ? Présentation de SEAL — Gestion décentralisée des secrets (DSM), désormais disponible sur le Sui Testnet. SEAL vise à corriger l'une des plus grandes hypocrisies du Web3 : crier à la décentralisation tout en utilisant secrètement AWS

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

# Vous me demandez peut-être : Qu'est-ce que SEAL ?

SEAL est un protocole qui vous permet de gérer les données sensibles de manière sécurisée et**décentralisée**, spécialement conçu pour le monde Web3. Considérez-le comme une couche de contrôle d'accès axée sur la confidentialité qui se connecte à votre DApp.



Vous pouvez considérer SEAL comme une sorte de verrou programmable pour vos données. Vous ne vous contentez pas de verrouiller et de déverrouiller des éléments manuellement : vous**inscrivez des politiques directement dans vos contrats intelligents**, à l'aide de Move on Sui.

Supposons que vous créiez une DApp où :

- Seuls les détenteurs de NFT peuvent débloquer un tutoriel premium
- Ou peut-être qu'un DAO doit voter avant que des fichiers sensibles ne soient révélés
- Ou vous souhaitez que les métadonnées soient verrouillées dans le temps et ne soient accessibles qu'après une date précise

SEAL rend tout cela possible. Le contrôle d'accès se fait *en chaîne*, entièrement automatisé, aucun administrateur n'est nécessaire pour le gérer. Juste de la logique, intégrée à la blockchain.

SEAL rend tout cela possible. Le contrôle d'accès se fait *en chaîne*, entièrement automatisé, aucun administrateur n'est nécessaire pour le gérer. Juste de la logique, intégrée à la blockchain.

Un autre élément intéressant est la façon dont SEAL gère le**chiffrement**. Il utilise ce que l'on appelle le**chiffrage à seuil**, ce qui signifie qu'aucun nœud ne peut déchiffrer les données. Il faut un groupe de serveurs pour fonctionner ensemble, un peu comme en mode multi-sig, mais pour débloquer des secrets. Cela permet de répartir la confiance et d'éviter le problème habituel de point de défaillance unique.

Et pour garantir la confidentialité des informations, SEAL chiffre et déchiffre tout**côté client**. Vos données ne sont jamais visibles par aucun backend. Il reste entre vos mains, littéralement, sur votre appareil.

et SEAL ne se soucie pas de l'endroit où vous stockez vos données. Qu'il s'agisse d'IPFS, d'Arweave, de Walrus ou d'une autre plateforme, SEAL n'essaie pas de contrôler cette partie. Il se concentre uniquement sur**qui est autorisé à voir quoi**, et non sur *où* les objets sont stockés.

> Donc oui, il ne s'agit pas simplement d'une bibliothèque ou d'une API, c'est une**couche de confidentialité par défaut**, dont l'accès est contrôlé et dont l'accès est contrôlé, pour votre DApp.


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


**SEAL comble une lacune assez critique**. Décrivons cela un peu plus. 

---

Si vous créez une DApp qui traite**toute forme de données sensible**(contenu sécurisé, documents utilisateur, messages cryptés, même des métadonnées NFT verrouillées dans le temps), vous rencontrerez le même problème :

➡️ Comment gérer les accès en toute sécurité, sans recourir à un service centralisé ?

Sans quelque chose comme SEAL, la plupart des équipes non plus :

1. Utilisez des outils centralisés tels qu'AWS KMS ou Firebase, ce qui va clairement à l'encontre de la décentralisation
2. Ou essayez de corriger vous-même une logique de chiffrement à moitié cuite, qui s'avère généralement fragile et difficile à auditer

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

Aucun de ces modèles n'est bien adapté. Surtout pas lorsque vous essayez de créer des applications fiables pour plusieurs chaînes ou communautés.

**SEAL rend l'ensemble de ce processus modulaire et programmable.**

Vous définissez vos règles d'accès dans les contrats intelligents Move, et SEAL s'occupe du reste (génération de clés, approbations de déchiffrement et application des droits d'accès), le tout sans que personne n'émette manuellement des clés ou n'effectue de vérifications en arrière-plan.

Mieux encore, ces règles sont**auditables et immuables** : une fois qu'elles sont connectées, elles suivent le contrat, pas un administrateur humain.

Donc, au lieu de demander « qui doit gérer l'accès à ces données ? » il vous suffit de demander :

> « Quelle logique devrait définir l'accès ? »
> > ... et laissez la chaîne s'en occuper. Propre et évolutif.

C'est ce qui rend SEAL pertinent pour bien plus que de simples « outils de sécurité » : c'est une couche de base pour**toute DApp soucieuse de la confidentialité, de la conformité ou de la logique d'accès dynamique.**

C'est un petit changement, mais cela change beaucoup la façon dont nous envisageons les données dans le Web3. Au lieu de chiffrer *après* le déploiement ou de faire appel à des services externes**, vous commencez par intégrer la confidentialité et l'accès entièrement géré par une logique de contrat intelligent.**

Et c'est exactement ce dont Web3 a besoin en ce moment.

---
# Comment fonctionne réellement SEAL ?
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

Nous avons expliqué**ce qu'est SEAL**et**pourquoi Web3 en a besoin**, voyons comment il est réellement construit sous le capot. C'est dans cette partie que les choses deviennent plus techniques, mais dans le bon sens. L'architecture est élégante une fois que vous voyez comment toutes les pièces s'emboîtent.

À un niveau élevé, SEAL fonctionne en combinant la**logique d'accès en chaîne**avec la**gestion des clés hors chaîne**, en utilisant une technique appelée**Identity-Based Encryption (IBE)**. Cela permet aux développeurs de crypter les données *sous forme d'identité*, puis de s'appuyer sur des contrats intelligents pour définir *qui est autorisé* à les déchiffrer.

## Étape 1 : Règles d'accès dans les contrats intelligents (sur Sui)

Tout commence par le contrat intelligent. Lorsque vous utilisez SEAL, vous définissez une fonction appelée seal_approve dans votre contrat Move. C'est là que vous écrivez vos conditions de déchiffrement.

Par exemple, voici une règle de verrouillage temporel simple écrite dans 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);
}
```

Une fois déployé, ce contrat fait office de gardien. Chaque fois que quelqu'un souhaite déchiffrer des données, sa demande sera vérifiée par rapport à cette logique. Si elle passe, la clé est relâchée. Si ce n'est pas le cas, ils sont bloqués. Personne n'a besoin d'intervenir.

##**Étape 2 : Chiffrement basé sur l'identité (IBE)**

C'est là que la magie opère.

Au lieu de chiffrer les données pour une adresse de portefeuille spécifique (comme avec PGP ou RSA), SEAL utilise des**chaînes d'identité**, ce qui signifie que vous chiffrez selon un format tel que :

- 0 x adresse du portefeuille
- dao_voted:proposal_xyz
- PKGID_2025_05_01 (règle basée sur l'horodatage)
- ou même game_user_nft_holder

Lorsque les données sont cryptées, elles se présentent comme suit :

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

- mpk = clé publique principale (connue de tous)
- identité = le destinataire défini par la logique
- message = les données réelles

Plus tard, si quelqu'un souhaite déchiffrer, le serveur de clés vérifie s'il correspond à la politique (via l'appel seal_approve onchain). S'il est approuvé, il renvoie une clé privée dérivée pour cette identité.

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

L'utilisateur peut ensuite déchiffrer le contenu localement.

Le cryptage est donc effectué sans avoir besoin de savoir *qui* va déchiffrer à l'avance. Il vous suffit de définir les *conditions*, et SEAL s'occupera du reste plus tard. C'est dynamique.


##**Étape 3 : Le serveur de clés — Offchain, mais pas centralisé**

Vous vous demandez peut-être : qui détient ces clés principales ?

C'est là qu'intervient le**Key Server**de SEAL. Considérez-le comme un backend qui :

- Contient la clé secrète principale (msk)
- Surveille les contrats en chaîne (comme votre logique seal_approve)
- N'émet des clés dérivées que si les conditions sont remplies

Mais, et c'est essentiel, SEAL ne s'appuie pas sur un seul serveur de clés. Vous pouvez l'exécuter en**mode seuil**, où plusieurs serveurs indépendants doivent être d'accord avant qu'une clé de déchiffrement ne soit émise.

Par exemple : 3 serveurs de clés sur 5 doivent approuver la demande. Cela évite les points de défaillance centraux et permet également la décentralisation au niveau de la couche de gestion clé.

Mieux encore, à l'avenir, SEAL prendra en charge le**MPC (calcul multipartite)** et les**configurations basées sur des enclave**(comme TEE), afin que vous puissiez obtenir des garanties encore plus strictes sans compromettre la convivialité.

##**Étape 4 : Décryptage côté client**

Une fois la clé renvoyée à l'utilisateur, le déchiffrement proprement dit s'effectue**sur son appareil**. Cela signifie que :

- Le serveur ne voit jamais vos données
- Le backend ne stocke jamais de contenu déchiffré
- Seul l'utilisateur peut accéder au message final

Il s'agit d'un modèle de confidentialité solide. Même si quelqu'un compromet la couche de stockage (IPFS, Arweave, etc.), il ne peut toujours pas lire les données sans passer la logique d'accès.

Voici le modèle mental rapide :

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

Cette structure facilite la création de dApps où les règles d'accès ne sont pas codées en dur : elles sont dynamiques, vérifiables et entièrement intégrées à votre logique de chaîne.

##**L'équipe derrière SEAL**

SEAL est dirigé par**Samczsun**, une figure bien connue de la communauté de la sécurité blockchain. Ancien partenaire de recherche chez Paradigm, il a audité et sauvé plusieurs écosystèmes contre des exploits majeurs. Maintenant, il se concentre à plein temps sur l'intégration de SEAL au cœur de l'infrastructure de confidentialité de Web3.

Grâce à son expérience et à sa crédibilité, SEAL n'est pas un simple outil expérimental comme les autres, mais une tentative sérieuse de rendre la confidentialité des données décentralisée à la fois pratique et évolutive.

Alors que SEAL est mis en ligne sur le Sui Testnet, il apporte une nouvelle norme sur la façon dont les applications Web3 peuvent gérer les secrets. En combinant le contrôle d'accès en chaîne, le cryptage des seuils et la confidentialité côté client, SEAL offre une base plus fiable pour le traitement décentralisé des données.

Que vous créiez des DApps, des DAO ou des jeux décentralisés, SEAL fournit une puissante boîte à outils pour renforcer le contrôle d'accès et protéger les données des utilisateurs sans compromettre la décentralisation.

Si le Web3 veut aller de l'avant, une infrastructure sécurisée comme SEAL n'est pas facultative, elle est essentielle

# 👀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- Je pense que la confidentialité des données Web3 est sur le point de changer

*J'essaie de comprendre cet aspect du réseau Sui parce que je suis en train de créer, de déboguer ou de déployer quelque chose qui touche à ce domaine. Je souhaite une explication détaillée du fonctionnement de ce mécanisme ou de cette fonctionnalité, ainsi que l'utilisation pertinente de la CLI, la structure du code Move ou les concepts architecturaux. Mon objectif est d'obtenir suffisamment de clarté pour appliquer ces connaissances à un projet réel, qu'il s'agisse d'un contrat intelligent personnalisé, d'un système NFT, d'une intégration de portefeuille ou d'un outil DeFi. Le réseau Sui possède des caractéristiques uniques par rapport aux chaînes EVM. Je m'intéresse donc particulièrement à ce qui le distingue et à la manière dont cela affecte les meilleures pratiques de développement. Il serait utile de disposer d'exemples de code, d'exemples de ligne de commande ou d'erreurs typiques à surveiller, en particulier lors de l'utilisation de la CLI Sui, du SDK ou d'un déploiement sur localnet/testnet. En fin de compte, je souhaite éviter les erreurs courantes, suivre les meilleurs principes de sécurité et m'assurer que les fonctionnalités sur lesquelles je travaille se comportent comme prévu dans des conditions réalistes. *

*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?

Comment fusionner deux pièces dans Move ?

J'essaie de comprendre cet aspect du réseau Sui parce que je suis en train de créer, de déboguer ou de déployer quelque chose qui touche à ce domaine. Je souhaite une explication détaillée du fonctionnement de ce mécanisme ou de cette fonctionnalité, ainsi que l'utilisation pertinente de la CLI, la structure du code Move ou les concepts architecturaux. Mon objectif est d'obtenir suffisamment de clarté pour appliquer ces connaissances à un projet réel, qu'il s'agisse d'un contrat intelligent personnalisé, d'un système NFT, d'une intégration de portefeuille ou d'un outil DeFi. Le réseau Sui possède des caractéristiques uniques par rapport aux chaînes EVM. Je m'intéresse donc particulièrement à ce qui le distingue et à la manière dont cela affecte les meilleures pratiques de développement. Il serait utile de disposer d'exemples de code, d'exemples de ligne de commande ou d'erreurs typiques à surveiller, en particulier lors de l'utilisation de la CLI Sui, du SDK ou d'un déploiement sur localnet/testnet. En fin de compte, je souhaite éviter les erreurs courantes, suivre les meilleurs principes de sécurité et m'assurer que les fonctionnalités sur lesquelles je travaille se comportent comme prévu dans des conditions réalistes.

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.

Sans réponse

Partagez vos connaissances et votre expertise.

Publications

Gagne ta part de 1000 Sui