Peera.

Explore

Connect with communities and discover new ideas.

Sui.X.Peera.

Earn Your Share of 1000 Sui

Gain Reputation Points & Get Rewards for Helping the Sui Community Grow.

Communities

Filter:All blockchains

Bounty

  • Xavier.eth.Peera.
    Xavier.eth313
    ForSuiJun 27, 2025
    +15

    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!

    2
    5
  • Xavier.eth.Peera.
    Xavier.eth313
    ForSuiJun 17, 2025
    +15

    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.

    0
    5
  • Peera Admin.Peera.
    Peera Admin37
    ForSuiMay 29, 2025
    +10

    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?

    5
    3

Newest

  • Bekky.Peera.
    Bekky40
    ForSuiJul 15, 2025

    How to Start Developing on Sui With No Blockchain Experience

    How to Start Developing on Sui With No Blockchain Experience Sui Network’s blazing-fast transactions and low fees have caught your attention – now you’re ready to build. But what if you have zero blockchain background? This guide takes you from absolute beginner to Sui developer in clear, actionable steps. * Step 1: Understand the Basics (No Coding Yet!)* What is Sui? A high-performance Layer 1 blockchain designed for scalability Uses Move language (more secure than Solidity) Ideal for DeFi, gaming, and NFTs due to low-cost transactions Key Concepts You Need: ✔ Smart Contracts – Self-executing blockchain code ✔ Wallets – Sui Wallet (Chrome extension) for dApp interaction ✔ Gas Fees – Minimal transaction costs ✔ dApps – Decentralized applications like exchanges or games * Step 2: Set Up Your Development Environment* 1. Install Sui CLI Mac/Linux Terminal:** curl -fsSL https://get.sui.io | bash Windows:** Use WSL (Windows Subsystem for Linux) 2. Get a Sui Wallet Install the Sui Wallet extension Fund with testnet SUI from Sui Discord faucet 3. Choose Your Code Editor VS Code* (recommended) + *Move Analyzer** extension * Step 3: Learn Move (Sui’s Programming Language)* Why Move? Prevents common bugs** through built-in safety features Easier for beginners** than Ethereum’s Solidity Free Learning Resources: 🔹 Sui Official Docs 🔹 Move Book 🔹 Sui Academy YouTube First Exercise: Deploy a Contract Create project: sui move new hello_sui Edit sources/hello.move Build & deploy: sui move build sui client publish --gas-budget 10000000 * Step 4: Build Your First dApp* Beginner Project Ideas: 1️⃣ Custom Token (Like a personal cryptocurrency) 2️⃣ NFT Collection (Digital art with blockchain proofs) 3️⃣ Simple Swap (Basic token exchange) Guided Tutorials: Coin Flip Game NFT Minting * Step 5: Join the Sui Community* Where to Connect: Discord:** Sui Dev Chat GitHub:** Sui Code Examples Hackathons:** Sui Events

    0
  • Evgeniy CRYPTOCOIN.Peera.
    Evgeniy CRYPTOCOIN196
    ForSuiJul 15, 2025

    AI Agents in Web3: Autonomous Bots and Their Use Cases

    The Rise of Autonomous Intelligence: How AI Agents Are Reshaping Web3 on Sui The Web3 revolution is entering its next evolutionary phase – one where autonomous AI agents increasingly participate alongside human users in decentralized ecosystems. These sophisticated programs represent a fundamental shift in how blockchain networks operate, with Sui emerging as a particularly fertile ground for their development due to its unique technical architecture. This comprehensive analysis examines: 🧠 The anatomy of Web3 AI agents and their operational frameworks 🌐 Transformative applications across DeFi, gaming, and governance ⚙️ Sui's structural advantages for autonomous agent deployment ⚠️ Critical challenges and existential risks requiring resolution 1. The Architecture of Web3 AI Agents Modern blockchain-based AI agents combine multiple advanced technologies into cohesive operational units: Core Components: Machine Learning Models** (Decision engines analyzing on/off-chain data) Smart Contract Interfaces** (On-chain execution mechanisms) Oracle Networks** (Real-world data feeds for contextual awareness) Tokenized Incentives** (Economic rewards for desired behaviors) Operational Example: An advanced DeFi management agent might: Analyze yield opportunities across 15+ protocols via Chainlink data feeds Simulate transaction outcomes using historical market models Execute optimized trades through permissionless smart contracts Reinvest profits based on predefined risk parameters 2. Revolutionary Use Cases Enabled by Autonomous Agents Financial Applications | Agent Type | Functionality | Sui Advantage | |------------------------|-------------------------------------------|----------------------------------| | Arbitrage Hunters | Cross-DEX price discrepancy exploitation | Sub-second finality enables frontrunning prevention | | Portfolio Optimizers | Dynamic rebalancing across yield sources | Low fees permit micro-adjustments | | Risk Managers | Real-time liquidation prevention | Move's safety prevents exploit vectors | Security & Compliance Smart Contract Auditors**: Continuous vulnerability scanning using formal verification Regulatory Compliance Bots**: Automated KYC/AML checks for DeFi protocols Anti-Fraud Sentinels**: Pattern recognition for wallet drainer attacks Decentralized Governance Proposal Analysis Engines**: Natural language processing of DAO discussions Voting Delegation Agents**: Algorithmic voting based on stake-weighted preferences Treasury Management Bots**: Autonomous execution of approved budgets Gaming & Virtual Economies Procedural Content Generators**: Dynamically creating NFT assets and quests NPC Behavior Systems**: Learning from player interactions to enhance realism Economic Balancers**: Adjusting token sinks/faucets based on inflation metrics 3. Sui's Structural Advantages for AI Agent Deployment Performance Characteristics Throughput Capacity**: 100,000+ TPS handles agent transaction volume Deterministic Finality**: <1s confirmation enables time-sensitive operations Predictable Fee Market**: No gas spikes disrupting agent economics Developer Benefits Move Language**: Strong typing prevents common smart contract vulnerabilities Object-Centric Model**: Granular data access for machine learning inputs Parallel Execution**: Agents operate without sequential processing bottlenecks Network Effects Growing Agent Ecosystem**: Early projects like Cetus integrating bot interfaces Interoperability Features**: Potential cross-chain agent communication 4. Critical Challenges and Risk Vectors Technical Limitations Oracle Reliability**: Off-chain data accuracy remains a single point of failure Model Opaqueness**: Difficulty auditing complex neural network decisions Blockchain Constraints**: On-chain ML inference still cost-prohibitive Economic Risks Reflexive Market Impacts**: Agent herding creating artificial volatility MEV Exploitation**: Sophisticated bots extracting value from simpler agents Governance Dilemmas Principal-Agent Problems**: Aligning bot behavior with owner intentions Regulatory Uncertainty**: Legal status of autonomous financial entities 5. The Road Ahead: Emerging Development Vectors Short-Term (2024-2025) Agent Standardization**: Common interfaces for bot interoperability Reputation Systems**: On-chain scoring for reliable agents Hybrid Architectures**: Off-chain computation with on-chain settlement Long-Term (2026+) Autonomous DAOs**: Fully self-governing protocol ecosystems Agent Marketplaces**: Trading specialized bots as tokenized assets Machine-to-Machine Economies**: Bots negotiating directly with each other Strategic Implications for the Sui Ecosystem The integration of AI agents presents both tremendous opportunities and complex challenges for Sui: Positive Impacts: Increased network utility and transaction volume New developer tools and infrastructure demands Enhanced protocol sophistication through automation Adoption Requirements: Improved oracle solutions for reliable off-chain data Standardized agent communication protocols Governance frameworks for autonomous entities Competitive Positioning: Sui's technical advantages in speed and security position it as a leader in the coming wave of intelligent Web3 applications, though success will depend on: Maintaining performance edge as other L1s evolve Fostering robust agent development tools Addressing regulatory concerns proactively Conclusion: The Dawn of Programmable Economies The emergence of AI agents represents more than just a technical innovation – it signals the beginning of self-operating digital economies where machine participants continuously optimize system performance. Sui's architecture makes it exceptionally well-suited to host this evolution, though the ecosystem must thoughtfully address: Security**: Ensuring agent behavior remains verifiable and constrained Decentralization**: Preventing concentration of agent control Ethics**: Establishing norms for autonomous decision-making As these challenges are addressed, we're likely to see Sui become a primary platform for the next generation of intelligent decentralized applications that blend human creativity with machine efficiency. Discussion Points: Which agent use case has the most immediate potential? How should DAOs govern interactions with autonomous agents? What safeguards are needed against malicious bot networks? Join the conversation about Web3's intelligent future.

    0
  • Arnold.Peera.
    Arnold40
    ForSuiJul 15, 2025

    What’s the best way to handle NFT metadata storage on Sui?

    I’m building an NFT project on Sui and trying to figure out the optimal approach for metadata storage. I’ve seen a few different strategies, but I’m not sure which one makes the most sense for balancing cost, flexibility, and compatibility. Here’s where I’m stuck: Cost Efficiency – Storing everything on-chain seems clean, but I’ve heard it can get expensive at scale. How are teams handling this without blowing through gas fees? Mutable vs. Immutable Data – Some traits (like artwork) should never change, but others (like game item stats) might need updates. What’s the best pattern for handling both cases? Off-Chain Storage – IPFS/Arweave seem popular, but how do you structure the on-chain references properly? Are there pitfalls to avoid? Marketplace Compatibility – I want my NFTs to show up correctly on major marketplaces. Are there Sui-specific metadata standards I should follow? I’d love to hear from developers who’ve shipped NFT collections on Sui: What storage approach worked best for you? Any gotchas or anti-patterns I should watch out for? How do you handle metadata updates without breaking things? Thanks in advance for any insights!

    0
    2

Unanswered

  • 24p30p.Peera.
    24p30p185
    ForSuiJul 12, 2025

    How to handle object version mismatches?

    Sometimes my transaction fails because the object version changed. How do I avoid or handle this issue reliably?

    0
    0
  • BitcoinADUK.Peera.
    BitcoinADUK10
    ForThe GraphMar 14, 2025

    GRT Token - what are your thoughts?

    The Graph (GRT) is a decentralized protocol designed to index and query data from blockchains, starting with Ethereum. It enables developers to build and publish open APIs, known as subgraphs, that make blockchain data easily accessible for decentralized applications (dApps). The native token, GRT, is utilized within the network by participants such as Indexers, Curators, and Delegators to ensure the economic security and integrity of the data being queried. As of March 14, 2025, GRT is trading at approximately $0.094, with a 24-hour trading volume of around $36 million. This current price reflects a significant decline from its all-time high of $2.84, indicating a downward trend over the past few years. The price trajectory of GRT has been influenced by various factors, including technological advancements, regulatory developments, and broader macroeconomic indicators. These elements have collectively contributed to the observed decrease in value over time. Please note that cryptocurrency markets are highly volatile, and past performance does not guarantee future results. It's essential to conduct thorough research and consider your financial situation before making any investment decisions.

    0
    0
  • Fractal Visions.Peera.
    Fractal Visions30
    ForFractal VisionsNov 17, 2024

    Fractal Visions MVP Launch

    Fractal Visions, a decentralized marketplace platform built on the superchain concept, has officially launched its new marketplace, positioning itself as a pivotal player in the blockchain ecosystem. This innovative marketplace leverages the power of the superchain—a scalable and interoperable blockchain network—to offer a seamless user experience for creators, collectors, and traders of digital assets. Here are some key highlights of the Fractal Visions marketplace: 1. Superchain Integration Fractal Visions has integrated the superchain infrastructure to ensure high scalability, low transaction costs, and fast settlement times. By tapping into this architecture, Fractal Visions can offer cross-chain interoperability, allowing users to transact seamlessly across different blockchain ecosystems. This is a significant advantage over traditional, isolated blockchain networks, providing users with more flexibility and access to a wider range of digital assets. 2. Decentralized Marketplace The Fractal Visions platform operates in a fully decentralized manner, empowering users to retain full control over their digital assets. Artists, creators, and collectors can freely trade and showcase NFTs and other digital items without the interference of centralized entities. This decentralized nature enhances transparency, reduces the risk of censorship, and provides a trustless environment for users. 3. User-Centric Features The marketplace is designed with the user experience in mind. It offers a simple, intuitive interface for easy browsing, buying, and selling of NFTs and other digital assets. Fractal Visions includes advanced search features, personalized recommendations, and an advanced bidding system for auction-style sales. 4. Multichain Support Fractal Visions supports multiple blockchains, allowing users to connect their wallets across various networks. This includes support for Optimism, Base, Mode, and other leading layer 2 networks. The multichain approach ensures that users can access a wide range of assets and interact with a large, global audience. 5. Focus on Creators Fractal Visions offers unique opportunities for creators to monetize their work. By providing creators with complete ownership of their assets and offering flexible revenue-sharing models, the platform ensures that artists and developers can thrive within a decentralized ecosystem. Additionally, creators can set up royalty structures, allowing them to earn income from secondary sales of their work. 6. Innovative Features The marketplace incorporates cutting-edge technology, such as AI-driven content recommendations and enhanced security features, ensuring that the platform remains at the forefront of blockchain-based marketplaces. Additionally, Fractal Visions is working on integrating VR (Virtual Reality) and AR (Augmented Reality) features to allow users to experience digital assets in immersive environments. 7. Community Engagement Fractal Visions is committed to building a strong community around its platform. The marketplace supports community-driven governance, allowing users to participate in decision-making processes and contribute to the evolution of the platform. Whether through voting on proposals or engaging in social interactions, users are at the heart of the ecosystem. 8. Sustainability and Eco-Friendliness As part of its commitment to sustainability, Fractal Visions is optimizing its network for energy efficiency, ensuring that the platform operates with a minimal environmental footprint. This aligns with the broader trend of eco-consciousness within the blockchain industry. Fractal Visions’ new marketplace launch marks a significant step forward in the evolution of decentralized, superchain-based platforms. By combining the power of interoperability, decentralization, and user-centric design, Fractal Visions is set to reshape how digital assets are created, traded, and experienced. The marketplace’s seamless integration with multiple blockchains, along with its focus on empowering creators and fostering community engagement, positions it as a major contender in the rapidly growing digital asset ecosystem.

    0
    0

Trending

  • Vens.sui.Peera.
    Vens.sui211
    ForSuiApr 29, 2025

    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

    8
    3
  • 0xduckmove.Peera.
    0xduckmove787
    ForSuiApr 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
  • MarlKey.Peera.
    MarlKey61
    ForSuiApr 30, 2025

    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.

    7
    3