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

  • Bolke .Peera.
    Bolke 237
    ForSuiAug 22, 2025
    +50

    How to Maximize Profit Holding SUI: Sui Staking vs Liquid Staking

    I'm looking for comprehensive answers to help the community understand the best strategies for earning with SUI tokens. This bounty is for detailed, well-researched responses that cover all aspects of SUI token earning opportunities. Questions seeking detailed answers: Sui Staking vs Liquid Staking What are the key differences between traditional staking and liquid staking on Sui? Which validators offer the best rewards and why? What are the risks and benefits of each approach? How do lock-up periods compare? Gas costs and operational differences? What are the Best Ways to Earn While Holding SUI? What are ALL available earning methods for SUI holders? DeFi protocols offering SUI yield farming opportunities Lending platforms that accept SUI LP provision strategies and best pairs Any other passive income methods? How to Maximize Profit from SUI Holdings? Step-by-step strategy for different portfolio sizes (small, medium, large holders) Risk management techniques Timing strategies for entering/exiting positions Tax considerations and optimization Tools and platforms for tracking performance

    4
    14
  • Bolke .Peera.
    Bolke 237
    ForSuiAug 12, 2025
    +15

    Sui Move Error - Unable to process transaction No valid gas coins found for the transaction

    When I do this: // Split payment from primary coin const [paymentCoin] = tx.splitCoins( tx.object(primaryCoin.coinObjectId), [tx.pure.u64(requiredPaymentAmount)] ); // Use the original coin for gas payment tx.setGasPayment([{ objectId: primaryCoin.coinObjectId, version: primaryCoin.version, digest: primaryCoin.digest }]); tx.setGasBudget(10_000_000); It complains about mutatable objects cannot appear more than one in one transaction. When I remove the gas payment, it complains "Unable to process transaction No valid gas coins found for the transaction.". My contract function accepts .01 sui in exchange for an NFT

    3
    16
  • Xavier.eth.Peera.
    Xavier.eth318
    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!

    4
    9

Newest

Unanswered

Trending

  • Gon.Peera.
    Gon58
    ForSuiAug 31, 2025

    Sui’s Big Picture: A Blockchain Operating System for Everything?

    Sui isn’t just pushing DeFi. The 10 being worked products in red — Walrus Millionaire (quests), *land (RWA), *human (personhood), updown (prediction markets), SuiSnaps (secret NFTs), CryptoGuard (DeFi security), *pay (new payments), Smash (social network), Drones/Humanoids (robots), RWA (tokenized assets) — show a much broader ambition. When combined with infrastructure projects like Walrus (storage), Scion (fast internet), internetless (low-signal mode), Prog Txn Block, Sponsored Txn, zkLogin, DeepBook, SuiBridge, Sui is positioning itself as a full-stack blockchain computer: handling storage, identity, finance, payments, social, entertainment, and even robotics — potentially able to run apps even in offline or low-connectivity environments. Is Sui truly building the first blockchain operating system that unifies all these layers? Which of these narratives — finance (RWA, CryptoGuard), social (Smash, SuiSnaps), or futuristic (internetless, robots) — will drive adoption first?

    14
    14
  • Vens.sui.Peera.
    Vens.sui213
    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

    9
    6
  • 0xduckmove.Peera.
    0xduckmove2078
    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