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- 426
- 426
- 360
Move is an executable bytecode language used to implement custom transactions and smart contracts.
Top postsTop members- 271
- 260
- 251
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- 40
- 38
- 36
The Graph is a decentralized protocol for indexing and querying blockchain data. The Graph makes it possible to query data that is difficult to query directly.
Top postsTop members- 2565
- 10
- 10
Aave is a decentralized non-custodial liquidity protocol where users can participate as depositors or borrowers.
Top postsTop members- 148
- 138
- 74
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
Cyfrin Updraft is an education platform specializing on teaching the next generation of smart contract developers
Top members- 1780
- 75
- 60
Web3 (also known as Web 3.0) is an idea for a new iteration of the World Wide Web which incorporates concepts such as decentralization, blockchain technologies, and token-based economics.
Top postsTop members- 397
- 193
- 141
Polygon is a decentralised Ethereum scaling platform that enables developers to build scalable user-friendly dApps with low transaction fees without ever sacrificing on security.
Top postsAnkr makes accessing Web3 easy for those who want to build and earn on the future web. Ankr is the main infrastructure provider for Polygon, BNB Smart Chain, and Fantom.
Top postsTop members- 89
- 43
- 34
Koii is a new way to design communications infrastructure that distributes computing authority across a wider group of personal devices.
Top postsTop members- 402
- 188
- 80
Functionland is replacing Cloud Storage and Service Subscription economy by introducing a new category of products, called Blockchain-Attached Storage. It creates value by auto-minting crypto for the users and allocating a share to the developers.
Solidity is an object-oriented, high-level language for implementing smart contracts. It is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM).
Top postsTop members- 76
- 55
- 46
Fractal Visions is a builder owned and operated creative web3 NFT project hub and a multifaceted & multidimensional experience. Bridging the gap between the physical and digital world.
Top members- 30
- 27
- 23
- Top postsTop members
- 12
- 11
- 10
Vyper is a relatively new, pythonic programming language used to write smart contracts. Vyper targets Ethereum Virtual Machine making it virtually impossible for developers to code misleading programs.
Top members- 40
- 22
- 20
Bounty
- +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?
52 - +10ForMoveMar 11, 2025
Sui Move vs Aptos Move - What is the difference?
Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?
21 - +10ForSuiMar 05, 2025
Multiple Source Verification Errors" in Sui Move Module Publications - Automated Error Resolution
Developers working with Sui Move frequently encounter issues related to "Multiple source verification errors found" when attempting to publish or upgrade modules. These errors occur due to mismatches between local dependencies and their on-chain counterparts, leading to failed publications and deployment challenges. Below is a consolidated example of the errors developers face: Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk This issue often arises due to: Mismatched versions between the local development environment (e.g., Sui CLI) and the on-chain state. Differences in package configurations across networks (e.g., Mainnet vs. Testnet). Missing or outdated dependencies in the on-chain environment. Key Questions How can we automate the detection and resolution of these dependency mismatches during the publication process? What tools or scripts can be developed to ensure that local dependencies always align with their on-chain counterparts? Is there a way to streamline this process by integrating dependency checks into existing CI/CD pipelines or enhancing the Sui SDK? Your task is to propose a solution that addresses these challenges, ensuring smoother and more reliable deployments for Sui Move developers. Make sure to post your solution below.
41
Newest
Manage Sui, MVR & Walrus CLIs All-in-One
What is SUIup SuiUp is a tool (think of it like “rustup for Sui”) that lets you install and manage different versions of Sui-related CLI tools all in one place. That means you can handle the Sui CLI, the Move Package Registry CLI (MVR), and the Walrus CLI all from one convenient tool Why Use SuiUp? 🧠 All-in-One Convenience: Instead of installing sui, mvr, and walrus separately (and trying to track each version), SuiUp handles it all for you. It allows easy installation and switching between versions of these CLIs — all in one place. Better DevX (Developer Experience): SuiUp dramatically simplifies version management. Need to test your dApp on a new Sui testnet release but also maintain an older version for another project? No problem — you can install multiple versions side-by-side and switch with a single command. Avoid PATH Conflicts: By managing binaries centrally, SuiUp helps prevent confusion around which version you're running. It installs default binaries in a dedicated directory (like ~/.local/bin on Mac/Linux) and warns you if that directory isn't in your PATH. Make sure that directory comes first in your PATH so it takes priority. Consistency Across Environments: For teams and open-source projects, SuiUp lets everyone sync to the same CLI versions easily. No more "works on my machine" issues. Quick Updates & Rollbacks: Upgrading or downgrading your CLI is as easy as one command. Try new releases with confidence — you can always switch back if needed. Getting Started with SuiUp Before using SuiUp, you need to install it on your system. SuiUp supports all major operating systems: Install with Script: curl -sSfL https://raw.githubusercontent.com/Mystenlabs/suiup/main/install.sh | sh Or with Cargo: cargo install --git https://github.com/Mystenlabs/suiup.git --locked Key Commands: Installing suiup install sui@testnet suiup install sui@devnet suiup install sui@testnet-1.40.1 suiup install mvr suiup install mvr@0.0.8 suiup install walrus -y Update installed tools: suiup update sui@devnet Set default version: suiup default set sui@testnet-1.44.2 suiup default set mvr@0.0.7 Show current version in use: suiup default get List available binaries: suiup list Bonus: Install from Nightly or Branch (Advanced Users Only) suiup install mvr --nightly suiup install mvr --nightly my_branch suiup install mvr --nightly --debug Troubleshooting 🚫 If suiup is not found → check your PATH If the wrong version is being used → ensure .local/bin is first in PATH Use which sui and suiup which to debug
1How can I map my SuiNS to a Walrus Site?
I've recently bought a SuiNS domain and I'm trying to map it to my Walrus Site, but it doesn't seem to work. I've followed some guides but get stuck with xxx.xx.walrus.site not functioning. Any advice on how to properly set this up?
03- ForSuiJun 04, 2025
How to Transfer a Specific Amount of SUI Tokens: Handling Coin Objects
How to Transfer a Specific Amount of SUI Tokens: Handling Coin Objects The Challenge Unlike traditional blockchains where token balances are simple numbers, SUI stores tokens as individual coin objects. This means if you have 3 SUI tokens, they exist as three separate objects (e.g., 1 SUI + 1 SUI + 1 SUI = 3 total), not as a single balance of "3 SUI". When you want to transfer a specific amount (like 2.5 SUI), you need to: Merge multiple coin objects if needed Split coins to get the exact amount Transfer the resulting coin object Code Example: Transferring 2.5 SUI Here's a complete TypeScript example showing how to handle this: import { SuiClient, getFullnodeUrl } from '@mysten/sui.js/client'; import { TransactionBlock } from '@mysten/sui.js/transactions'; import { Ed25519Keypair } from '@mysten/sui.js/keypairs/ed25519'; // Initialize client and keypair const client = new SuiClient({ url: getFullnodeUrl('testnet') }); const keypair = Ed25519Keypair.fromSecretKey(YOUR_SECRET_KEY); const senderAddress = keypair.getPublicKey().toSuiAddress(); async function transferSUI(recipientAddress: string, amountInSUI: number) { try { // Convert SUI to MIST (1 SUI = 1,000,000,000 MIST) const amountInMist = Math.floor(amountInSUI * 1_000_000_000); // Step 1: Get all SUI coin objects owned by sender const coinObjects = await client.getCoins({ owner: senderAddress, coinType: '0x2::sui::SUI' }); if (coinObjects.data.length === 0) { throw new Error('No SUI coins found'); } console.log(Found ${coinObjects.data.length} SUI coin objects); coinObjects.data.forEach((coin, index) => { console.log(Coin ${index + 1}: ${coin.balance} MIST); }); // Step 2: Create transaction block const txb = new TransactionBlock(); // Step 3: Handle coin merging and splitting let primaryCoin; if (coinObjects.data.length === 1) { // Single coin - just split it primaryCoin = coinObjects.data[0].coinObjectId; } else { // Multiple coins - merge them first primaryCoin = coinObjects.data[0].coinObjectId; const coinsToMerge = coinObjects.data.slice(1).map(coin => coin.coinObjectId); if (coinsToMerge.length > 0) { txb.mergeCoins(primaryCoin, coinsToMerge); console.log(Merging ${coinsToMerge.length} coins into primary coin); } } // Step 4: Split the exact amount needed const [transferCoin] = txb.splitCoins(primaryCoin, [amountInMist]); // Step 5: Transfer the split coin txb.transferObjects([transferCoin], recipientAddress); // Step 6: Set gas budget and execute txb.setGasBudget(10000000); // 0.01 SUI in MIST const result = await client.signAndExecuteTransactionBlock({ signer: keypair, transactionBlock: txb, options: { showEffects: true, showObjectChanges: true, }, }); console.log('Transaction successful!'); console.log('Digest:', result.digest); console.log('Gas used:', result.effects?.gasUsed); return result; } catch (error) { console.error('Transfer failed:', error); throw error; } } // Usage example async function main() { const recipientAddress = '0x742d35cc6db7e3b6c7e4c46e7f8c7e6f1234567890abcdef'; const amountToTransfer = 2.5; // SUI await transferSUI(recipientAddress, amountToTransfer); } // Run the transfer main().catch(console.error); Step-by-Step Breakdown 1. Fetch Coin Objects const coinObjects = await client.getCoins({ owner: senderAddress, coinType: '0x2::sui::SUI' }); This retrieves all SUI coin objects owned by your address. 2. Merge Multiple Coins (if needed) if (coinObjects.data.length > 1) { const primaryCoin = coinObjects.data[0].coinObjectId; const coinsToMerge = coinObjects.data.slice(1).map(coin => coin.coinObjectId); txb.mergeCoins(primaryCoin, coinsToMerge); } If you have multiple coin objects, merge them into one larger coin. 3. Split Exact Amount const [transferCoin] = txb.splitCoins(primaryCoin, [amountInMist]); Split the exact amount you want to transfer from the merged coin. 4. Transfer the Split Coin txb.transferObjects([transferCoin], recipientAddress); Transfer the newly created coin object to the recipient. Key Points to Remember MIST vs SUI**: Always convert SUI to MIST (multiply by 1,000,000,000) when working with transactions Gas Budget**: Set an appropriate gas budget (usually 0.01 SUI is sufficient) Object IDs**: Each coin has a unique object ID that you reference in transactions Atomic Operations**: All merge, split, and transfer operations happen in a single transaction Error Handling Tips // Check if you have enough balance const totalBalance = coinObjects.data.reduce((sum, coin) => sum + parseInt(coin.balance), 0 ); if (totalBalance < amountInMist) { throw new Error(Insufficient balance. Have: ${totalBalance/1e9} SUI, Need: ${amountInSUI} SUI); } Alternative: Using SUI SDK's Built-in Method For simpler use cases, you can use the SDK's convenience method: const txb = new TransactionBlock(); const [coin] = txb.splitCoins(txb.gas, [amountInMist]); txb.transferObjects([coin], recipientAddress); This uses the gas coin for the transfer, which works well for smaller amounts. However, if gas coin does not have required amount of SUI the above approach is required/
1
Unanswered
- ForFunctionlandApr 14, 2025
Setting up NAS or BAS
While trying to use my tower as a NAS I followed the instructions, but this is the result: PS C:\WINDOWS\system32> ssh pi@fulatower ssh: Could not resolve hostname fulatower: Host is onbekend. PS C:\WINDOWS\system32> ssh pi@192.168.1.150 ssh: connect to host 192.168.1.150 port 22: Connection timed out
00 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- ForMoveMar 29, 2025
Is it easy to learn Move after solidity?
I know solidity and have made some projects on it,I was wondering if it would be easy for me to learn Move and that to in less time..like less than a month?
00
Trending
- 0xduckmove333ForSuiApr 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 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
62- Foksa225ForPeera MetaJul 25, 2022
How to create an account
To create an account on the Peeranha website you need to log in first. Peeranha supports four wallets you can log in with: Torus, MetaMask, WalletConnect, and Coinbase. Note: If you are new to Web3 we recommend you to use Torus. Log in with Torus Click Log in. Select the checkbox I agree to the Terms and Conditions and Privacy Policy. Choose Torus in the pop-up window. Select any of the suggested ways you want to sign in or enter your email address. You are now logged in and have an account. In your profile section, you can add more detailed information about yourself and track your progress and achievements. To edit your profile, click Profile and select Edit. Enter all the information that you want to be visible in your profile.
5