Explore
Connect with communities and discover new ideas.
Communities
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
Top postsTop members- 701
- 618
- 595
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Top postsTop members- 271
- 260
- 251
Peera is a decentralized questions and answers protocol for Web3 where users can organize and store their interests and skills, creating a common community platform
Top members- 328
- 286
- 225
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.
Top postsTop members- 25
- 20
- 20
Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"
Top postsTop members- 41
- 40
- 38
Bounty
- +15Xavier.eth313ForSuiJun 27, 2025
Sui Transaction Failing: Objects Reserved for Another Transaction
I'm encountering a persistent JsonRpcError when trying to execute transactions on Sui. The error indicates that objects are reserved for another transaction, even though I've implemented sequential transaction processing with delays. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 I've tried: Sequential transaction execution (waiting for previous transaction to complete) Added 3-second delays between transactions And still getting the same error consistently. Using Sui RPC for transaction submission. The same object ID appears multiple times in the lock list. Error occurs even with careful transaction sequencing. What causes objects to be "reserved" for other transactions? How can I properly check if an object is available before using it in a transaction? Are there best practices for handling object locks in Sui? Could this be related to transaction finality timing? Has anyone encountered this issue before? Any insights on proper object management in Sui transactions would be greatly appreciated!
24 - +15Xavier.eth313ForSuiJun 17, 2025
How do ability constraints interact with dynamic fields in heterogeneous collections?
I'm building a marketplace that needs to handle multiple asset types with different ability requirements, and I've hit some fundamental questions about Move's type system. I want to store different asset types in the same collection, but they have different abilities: Regular NFTs: key + store (transferable) Soulbound tokens: key only (non-transferable) Custom assets with transfer restrictions public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Key Questions: Ability Requirements: When using dynamic_field::add(), does V always need store at compile time? Can wrapper types work around this? Heterogeneous Storage: Can a single Bag store objects with different ability sets (key + store + copy vs key + store), and handle them differently at runtime? Type Safety: Since dynamic fields perform type erasure, how do I maintain type safety when retrieving values? What's the pattern for storing type metadata? Witness Pattern: How do ability constraints work with phantom types? Can I store Asset and Asset in the same collection and extract type info later? Building a system where NFTs, soulbound tokens, and restricted assets all need marketplace functionality but with different transfer semantics. I’ve tried wrapper types, multiple collections per ability set, separate type metadata storage. Each has tradeoffs between type safety, gas costs, and complexity.
04 - +10ForSuiMay 29, 2025
Why does BCS require exact field order for deserialization when Move structs have named fields?
Why does BCS require exact field order for deserialization when Move structs have named fields? I've been diving deep into BCS encoding/decoding in Move, particularly for cross-chain communication and off-chain data processing. While working through the examples in the Sui Move documentation, I encountered some behavior that seems counterintuitive and I'm trying to understand the underlying design decisions. According to the BCS specification, "there are no structs in BCS (since there are no types); the struct simply defines the order in which fields are serialized." This means when deserializing, we must use peel_* functions in the exact same order as the struct field definition. My Specific Questions: Design Rationale: Why does BCS require exact field order matching when Move structs have named fields? Wouldn't it be more robust to serialize field names alongside values, similar to JSON or other self-describing formats? Generic Type Interaction: The docs mention that "types containing generic type fields can be parsed up to the first generic type field." Consider this structure: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } How exactly does partial deserialization work here? Can I deserialize up to more_metadata and ignore both generic fields, or does the first generic field (generic_data) completely block further deserialization? Cross-Language Consistency: When using the @mysten/bcs JavaScript library to serialize data that will be consumed by Move contracts, what happens if: I accidentally reorder fields in the JavaScript object? The Move struct definition changes field order in a contract upgrade? I have nested structs with their own generic parameters? Practical Implications: In production systems, how do teams handle BCS schema evolution? Do you version your BCS schemas, or is the expectation that struct field order is immutable once deployed?
53
Newest
How to recover SUI coins from an old wallet?
I've been trying to locate my SUI coins when setting up a new Slush account, but I don't see them. How can I verify if I'm using the correct phrase to import my old wallet?
02Mastering Move Language Concepts – Course #2
While Course #1 i've made before introduced you to the basics of writing smart contracts in Move and building simple dApps on the Sui blockchain, this course focuses on deepening your understanding of the Move language itself — from its powerful type system to advanced patterns like generics, events, modules, and access control mechanisms. By the end of this course, you’ll be able to: Write modular, reusable, and secure Move code Use generics, abilities, and resource types effectively Implement fine-grained access control using capabilities Emit and listen to events for off-chain integration Work with complex data structures like tables and vectors Understand how Move differs from other smart contract languages like Solidity Let’s dive into the heart of the Move language! Step 1: Understanding Move’s Core Language Features Move is designed with safety and clarity in mind. Let's explore some of the most important features that make Move unique as a smart contract language. 1.1 Resource-Oriented Programming (Revisited) At the core of Move is the concept of resources, which are special types that cannot be copied or deleted unless explicitly allowed. This enforces safe handling of digital assets like tokens or NFTs. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } In this example: MyToken is a resource because it has the key ability. It can be stored (store) and uniquely identified by its id. It cannot be duplicated or dropped unless specified. This guarantees that each MyToken instance is uniquely owned and managed, preventing accidental duplication or deletion. 1.2 Abilities System Every type in Move has a set of abilities that define what operations it supports: | Ability | Meaning | |--------|---------| | copy | Can be duplicated | | drop | Can be discarded without destruction | | store | Can be stored in global storage | | key | Can be used as a struct with an ID field (i.e., an object) | Example: struct Example has copy, drop { value: u64 } Understanding these abilities is essential for designing secure and predictable smart contracts. Why Abilities Matter Abilities enforce strict rules at compile time. For instance: A struct with only key and store cannot be copied or dropped. You cannot return a non-droppable struct from a function unless it's stored or transferred. This prevents bugs like double-spending or accidental token loss. 1.3 Generics and Type Parameters Move supports generic types, allowing developers to write flexible and reusable code. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } Here, ` is a type parameter, making Box` work with any type while still being safe and efficient. Note: The phantom keyword indicates that T doesn’t affect the runtime representation of the struct — useful for abstract modeling. Step 2: Modular Development and Package Management As your Move projects grow in complexity, organizing your code becomes critical. 2.1 Creating and Publishing Move Packages A Move package contains one or more modules and defines dependencies. It's the unit of deployment and versioning in Move. Directory structure: sources/ place.move user.move Move.toml Define dependencies in Move.toml: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } You can publish packages to the Sui network and reuse them across multiple dApps. 2.2 Reusing Existing Modules The Sui Framework provides battle-tested modules like coin, transfer, and tx_context. Always check what’s available before writing custom logic. For example, to transfer an object: use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } Using standard libraries ensures safer, faster development and better interoperability. Step 3: Events and Off-Chain Communication To build real-world applications, your Move contracts need to communicate with off-chain systems like frontends or indexers. 3.1 Emitting Events Move allows emitting events that can be indexed by external services. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } This event will appear on the blockchain and can be picked up by explorers or indexing tools. 3.2 Listening to Events Use tools like Suiet Explorer, Subsquid, or the Sui JSON-RPC API to listen for emitted events and react accordingly in your application. In JavaScript/TypeScript: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); Step 4: Access Control and Security Patterns Security is paramount when dealing with smart contracts. Move provides several tools to implement robust access control. 4.1 Object Ownership Model Sui enforces ownership at the protocol level. Only the owner of an object can mutate or transfer it. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } Only the current owner can call this function. 4.2 Capabilities Pattern For more granular permissions, use the capability pattern — create special objects that grant limited access to certain functions. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } Now only users who hold the AdminCap can execute restricted_action. This pattern is widely used in DeFi and DAOs to delegate authority securely. Step 5: Working with Complex Data Structures Move supports structured data types that allow developers to model complex logic and relationships. 5.1 Vectors Vectors are used to store ordered collections of items of the same type. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; They’re useful for storing lists of NFTs, user roles, or dynamic metadata. Example usage: vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 Tables (via Sui Standard Library) While Move doesn’t natively support maps or hash tables, Sui provides the Table type in its standard library. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } Use tables to manage large datasets efficiently. Step 6: Testing and Debugging Your Contracts Testing ensures your Move code behaves as expected under various conditions. 6.1 Unit Testing in Move Write unit tests directly in your Move modules using the testing framework. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } Run tests with: sui move test 6.2 Using Sui Explorer After deploying your contract, use the Sui Explorer to inspect transactions, view object states, and debug issues. Step 7: Real-World Applications of Advanced Move Concepts Now that you understand the core language features, let’s explore how they apply to real-world scenarios. 7.1 NFT Minting Platform Create a platform that allows users to mint NFTs backed by Move resources, leveraging the ownership and resource models. 7.2 DAO Voting System Implement a decentralized autonomous organization (DAO) using Move for voting, proposals, and governance, using events and capabilities for secure actions. 7.3 Token Swaps and AMMs Build a decentralized exchange (DEX) using Move modules to represent liquidity pools and token swaps, using generics and tables for efficient state management.
2- ForSuiJun 30, 2025
What Are Dynamic NFTs, and Why Does Sui Excel at Them?
The NFT space is evolving beyond static images and profile pictures (PFPs). The next frontier? Dynamic NFTs (dNFTs)—tokens that can change based on real-world data, user interactions, or on-chain events. While many blockchains support NFTs, Sui Network is uniquely positioned to power the future of dNFTs thanks to its innovative architecture. This article explores: What makes an NFT "dynamic"? Why Sui’s technology is perfect for dNFTs Real-world use cases today The future of interactive digital assets 1. What Are Dynamic NFTs? Unlike traditional NFTs (which are static and immutable), dynamic NFTs can update their: Metadata (e.g., a sports NFT that changes based on game stats) Appearance (e.g., an artwork that evolves over time) Utility (e.g., a loyalty NFT that unlocks new perks) How Do They Work? dNFTs use smart contract logic + external data inputs (oracles, user actions, etc.) to trigger changes. Example: A weather-sensitive NFT artwork that shifts colors based on real-time climate data. A game character NFT that levels up as you play. 2. Why Sui is the Best Blockchain for Dynamic NFTs While Ethereum and Solana also support dNFTs, Sui’s design offers key advantages: On-Chain Storage (No External Dependencies) Most blockchains store NFT metadata off-chain (e.g., IPFS), making dynamic updates clunky. Sui stores everything on-chain, enabling instant, trustless modifications. Move Language: Safe & Flexible Upgrades Ethereum’s Solidity requires complex proxy contracts for upgradable NFTs. Sui’s Move language allows native mutability—no clunky workarounds. Parallel Processing (Massive Scalability) Updating thousands of dNFTs at once? Ethereum struggles with congestion. Sui’s parallel execution handles millions of updates without slowdowns. Object-Centric Model (Granular Control) Each NFT is an independent object with customizable logic. Enables fine-tuned interactivity (e.g., only the owner can trigger changes). 3. Real-World Use Cases of dNFTs on Sui Gaming & Metaverse Evolving in-game items (e.g., a sword NFT that gains abilities with use). Cross-game interoperability (Sui’s objects can move between dApps). Example: Sui-based games like Panzerdogs use dNFTs for customizable avatars. Generative & Reactive Art AI-powered NFTs that shift style based on market trends. Collaborative art where collectors influence the final piece. Example: Art labs like Sui Gallery host dNFT exhibitions. Real-World Asset (RWA) Tracking Deed NFTs that update with property records. Certification badges that expire or renew automatically. Loyalty & Membership Programs Dynamic discount NFTs that improve with customer spending. VIP access passes that unlock new tiers over time. Example: Sui’s retail partners are testing dNFT loyalty programs. 4. The Future of dNFTs on Sui Expect to see: AI-integrated dNFTs (e.g., chatbots living in NFT avatars). DeFi-collateralized dNFTs (value adjusts based on market conditions). Fully on-chain games where every asset is a mutable dNFT. Conclusion: Sui is Building the Future of NFTs While static NFTs dominated 2021-2023, dynamic NFTs will rule the next bull run—and Sui’s tech makes it the ideal platform. With **on-chain storage, Move’s security, and unmatched scalability, Sui is poised to become the home of advanced dNFTs.
5
Unanswered
How to update a merchant's key in ObjectTable when it changes in the struct?
Hi everyone, I'm just getting started with writing smart contracts and I'm working on my very first project. I'd love some help with an issue I'm stuck on. So far, I’ve created a Merchant struct that looks like this: id: a unique identifier (UID) owner: the address of the merchant key: a String used as a unique key balance: a u64 representing their balance I also made a MerchantRegistry struct to manage all merchants: id: another UID merchant_to_address: an ObjectTable mapping addresses to merchants merchant_to_key: an ObjectTable mapping keys to merchants I want to be able to look up a merchant either by their address or by their key. When a user updates their key inside the Merchant struct, the change doesn’t automatically update the key in the merchant_to_key table. That means the old key still points to the merchant, which breaks things. I tried removing the entry from the table and inserting it back with the new key, but I keep running into errors like: "Cannot ignore values without drop ability" I'm pretty sure this is a beginner mistake, but I haven't been able to find a clear explanation or solution anywhere. Is there a proper way to handle updating the key in both the struct and the lookup table?
50- 0xduckmove618ForSuiJun 06, 2025
Whats the easiest frontend to upload walrus blobs?
just a simple ui to upload to walrus? (besides tusky)
20 What happens if I don't claim ETH via Sui bridge?
I've been using the Sui bridge to transfer some ETH but haven't claimed it yet because the fees are quite high. What will happen if I leave it unclaimed?
00
Trending
AMM Bot in Sui Ecosystem
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
82- 0xduckmove618ForSuiApr 08, 2025
👀 SEAL- I Think Web3 Data Privacy Is About to Change
👀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 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. 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: Use centralized tools like AWS KMS or Firebase, which clearly goes against decentralization 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? 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: entry fun seal_approve(id: vector, 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: 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. 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: 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
8 Is the only way to publish Move packages through an EOA?
I assume there is no way on Sui chain as there is no module on chain which publishes packages.
73