Newest
Stay updated with the latest posts.
Posts
1677- DiscussionForSuiMar 08, 2025
Mistakenly withdrew to SUI instead of APTOS, any recovery options?
Hey folks, I recently made a withdrawal from Bybit and mistakenly used the SUI network instead of APTOS. I withdrew USDT to a SUI wallet, but it doesn't support USDT. I've already checked, and there's no recent activity. I also confirmed the withdrawal was processed by Bybit, but the transaction hash I have isn't valid on the SUI network. Unfortunately, this means my assets might be lost. Is there any way to recover my funds or am I out of luck?
- Sui
- Architecture
00 - DiscussionElvin CLONE 206ForSuiMar 08, 2025
Where to buy $SUI in New York State?
I'm trying to find where I can buy $SUI while being based in New York State. Could anyone help me with the platforms or exchanges available for purchasing $SUI here?
- Sui
00 - ArticleForSuiMar 08, 2025
Sui Fam Official - Mar 7th 2025
Sup Sui Fam, im Ed (crypto research and analyst) I contribute on Sui Foundation as Video Editor for Sui Official Community on X Enjoy the News and Alphas for this Week on Sui! Follow Sui Fam Offical Channel on X: https://x.com/SuiFamOfficial My X Profile: https://x.com/EdCryptoFi
- Sui
0 Does calling withdraw on MaticWETH trigger automatic steps?
I'm trying to understand the process within the Polygon network for transferring MaticWETH tokens back to the Ethereum network. When I call the withdraw function on a token like MaticWETH, it seems to trigger a Transfer event to the zero address. Does this event automatically initiate the first few steps required to bridge the token back to Ethereum, simply because the token is already mapped?
- MATIC
00- DiscussionForSuiMar 08, 2025
USDT not showing after bridging from Sui to Ethereum
I recently bridged some USDT from my Sui wallet to Ethereum. Although I didn't confirm the transaction from my EVM wallet, the USDTs were withdrawn from Sui but have not shown up in my EVM wallet. Can you help me resolve this issue?
- Sui
- Architecture
02 - ArticleForSuiMar 08, 2025
This article aims to learn and understand the #UTXO model from $BTC to $SUI
This article aims to learn and understand the UTXO model. It uses an easy-to-understand way to simply sort out the UTXO models and implementation methods from $BTC to $SUI. I will provides a comprehensive overview, which we expand here for clarity and depth, ensuring a professional and thorough analysis. As one of the core design principles of Bitcoin, the UTXO model has become an important technical paradigm in the blockchain field since its birth. It plays an important role in ensuring transaction security and traceability, and provides another path besides the traditional account balance model. As blockchain technology has been continuously updated and iterated in recent years, the UTXO model itself has also been constantly evolving and expanding. Introduction to UTXO and Its Origins The UTXO model, or Unspent Transaction Output, is a fundamental concept in Bitcoin, where each transaction output that hasn’t been spent is tracked as a UTXO. This model treats transactions like cash, where spending involves selecting specific UTXOs to cover the amount, as opposed to modifying a single balance. The example: Alice and Bob each start with 5 dollars. In the account model, if Bob robs Alice of 2 dollars, Alice’s balance becomes 3, and Bob’s becomes 7. In the UTXO model, Alice’s 5-dollar UTXO is spent to create two new UTXOs: 2 dollars to Bob and 3 dollars back to Alice, with Bob now holding his original 5-dollar UTXO and the new 2-dollar one, totaling 7 dollars. This approach, as detailed in Understanding UTXO: A Comprehensive Guide, ensures transparency and prevents double-spending, with each UTXO publicly tracked on-chain while preserving privacy through anonymous addresses. It is not difficult to see that Alice is left with 3 dollars and Bob is left with 7 dollars. This accounting method, which is similar to elementary school addition and subtraction, frequently appears in the banking system and is called the account/balance model. In it, the balance of an account exists as a single value. If a different approach from the account model is used, such as UTXO to represent the wealth transfer between Alice and Bob, the diagram will look different: Comparison with Account/Balance Model The account/balance model, common in banking, maintains a single balance per account, updated with each transaction Its simplicity but notes state contention issues when multiple transactions modify the same account, often requiring locks and causing performance bottlenecks, especially under high transaction volumes. In contrast, the UTXO model, as explained in Exploring the UTXO Model: What Sets It Apart in the Blockchain World?, avoids this by processing transactions on independent UTXOs, enabling parallel execution without locks, thus improving throughput and concurrency. Privacy is another advantage, with crypto wallets generating new addresses per transaction, making it harder to link to individuals, unlike the account model’s fixed addresses, which are more susceptible to correlation analysis. However, the UTXO’s limitations in handling complex business logic, such as multi-stage contracts, which led to Ethereum’s account-based model, as mentioned in What is a UTXO? Unspent Transaction Output Explained . SUI’s Object Model: Bridging UTXO and Account Models SUI, as detailed in the X post and supported by Object Model | Sui Documentation, centers storage around objects, not accounts, with two key types: OwnedObject (address-owned) and SharedObject. The OwnedObject enhanced UTXO, where only the owner can operate, and each version is spent once, aligning with UTXO’s principles. For instance, an address-owned object can only be modified by its owner, similar to spending a UTXO. SharedObject, conversely, is accessible to everyone, akin to the account model, but requires consensus to order reads and writes, addressing state contention, as noted in Sui Components | Sui Documentation. This is managed through special processing like local sorting. The Sui's Object-Oriented Approach highlights how SUI’s model impacts scalability, security, and user experience. Ownership Types in SUI | Ownership type | Description | Accessibility |--------|--------|-------- | Address-owned | Owned by a specific 32-byte address (account address or object ID) | Only accessible to its owner | Immutable | Can't be mutated, transferred, or deleted; no owner | Accessible to anyone | Shared | Shared using 0x2::transfer::share_object function | Accessible to everyone | Wrapped | Organizes data structures by putting a field of struct type in another | Not specified Owned objects include address-owned, aligning with UTXO, while shared objects are explicitly accessible to all, fitting the account model’s broader access. My conclusion and Future Considerations The transition from Bitcoin’s UTXO to SUI’s object model represents a significant evolution, offering flexibility and addressing UTXO’s limitations in complex logic through SharedObject, while retaining UTXO’s concurrency benefits via OwnedObject. This dual approach, as explored in Exploring Sui’s Object-Centric Model and the Move Programming Language, positions SUI as a versatile platform, potentially setting a new standard for blockchain data models.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
0 - DiscussionForSuiMar 07, 2025
Can you transfer SUI coins directly to Ledger Stax?
I am interested in storing my SUI coins on a Ledger Stax. I would like to know if it's possible to directly transfer SUI from an exchange or SUI wallet to a Ledger Stax. If it is, I plan to make a transfer. Does anyone have information on the current support for this process?
- Sui
01 - ArticleForSuiMar 07, 2025
Developing a Dice Game Contract in Sui Move
In this tutorial, I’ll guide you through the process of creating a dice game smart contract using Sui Move. This contract enables players to bet on the outcome of a dice roll, with an admin managing the prize pool. By the end, you'll have a fully functional contract and a solid understanding of several key Sui Move concepts. Introduction The dice game contract we'll build allows for the following functionalities: Initialization: The contract creator sets up the game. Admin Management: An admin can deposit tokens into the prize pool and withdraw them as needed. Player Interaction: Players participate by guessing the dice roll outcome and placing bets. This tutorial assumes you have a basic understanding of Sui Move and focuses on introducing new concepts through practical implementation. Before dive into the code, let’s explore the key concepts you’ll encounter: 1.1 Adding Dependencies: To use tokens from another contract (e.g., a faucet token contract), you need to add it as a dependency in your project. This is done by updating the Move.toml file of your contract: [dependencies] coin_duck = { local = "../coin_duck"”} Here, coin_duck is the faucet token contract located at the specified path. The depended contract must also specify its published-at field in its own Move.toml with the package ID obtained upon publication, like so: rust published-at = "packageId_from_publication" 1.2 Using Assertions Assertions ensure that certain conditions are met during contract execution. The assert! macro checks a condition and, if it fails, throws an error and halts execution. This is useful for preventing invalid states, such as betting more than a player’s balance. 1.3 Generating Random Numbers Fairness in the dice game relies on random number generation. Sui Move provides the random module for this purpose. You’ll create a RandomGenerator object and use it to generate a random number between 1 and 6, simulating a dice roll. 1.4 Working with Coin and Balance In Sui Move, tokens are managed using the coin and balance modules: Coin: A wrapper around Balance, used for transferring tokens. Balance: Represents the actual token amount, allowing operations like splitting and merging. Key methods include: coin::value(in_coin): Returns the total value of a Coin object. coin::take(&mut balance, amount, ctx): Extracts a specified amount from a Balance to create a Coin. in_coin.balance_mut().split(amount): Splits a specified amount from a Coin’s Balance. balance.join(balance): Merges one Balance into another. These operations will be used to manage the game’s prize pool and player bets. The Dice Game Contract Here’s the complete code for the dice game contract, followed by detailed explanations: /// Game: Dice rolling. Players bet and guess the number. If correct, they win an amount equal to their bet; if incorrect, the bet goes to the game pool. module game_duck:game_duck; use sui::balance::{Self, Balance}; use sui::coin::{Self, Coin}; use sui::random::{Random, new_generator, generate_u8_in_range}; use coin_duck::duckfaucet::DUCKFAUCET; const ErrorUserInsufficient: u64 = 0x101; const ErrorGameInsufficient: u64 = 0x102; public struct Game has key { id: UID, pool_amount: Balance, } public struct Admin has key { id: UID, } fun init(ctx: &mut TxContext) { let game = Game { id: object::new(ctx), pool_amount: balance::zero() }; transfer::share_object(game); let admin = Admin { id: object::new(ctx) }; transfer::transfer(admin, ctx.sender()); } public entry fun addCoinToGamePool(game: &mut Game, in_coin: &mut Coin, amount: u64, _: &mut TxContext) { let value = coin::value(in_coin); assert!(amount = amount, ErrorGameInsufficient); let coin = coin::take(&mut game.pool_amount, amount, ctx); transfer::public_transfer(coin, ctx.sender()); } entry fun play(game: &mut Game, random: &Random, guess_num: u8, in_coin: &mut Coin, amount: u64, ctx: &mut TxContext) { assert!(game.pool_amount.value() >= (amount * 3), ErrorGameInsufficient); assert!(in_coin.balance().value() >= amount, ErrorUserInsufficient); let mut g = new_generator(random, ctx); let win_num = generate_u8_in_range(&mut g, 1, 6); if (win_num == guess_num) { let reward_coin = coin::take(&mut game.pool_amount, amount, ctx); in_coin.join(reward_coin); } else { addCoinToGamePool(game, in_coin, amount, ctx); } } Code Breakdown structure Game: A shared object with a unique id and a pool_amount (Balance) to store the prize pool. Admin: A key object owned by the admin for Initialization (init)managing the pool. Initialization (init): Creates a Game object with an empty prize pool and shares it publicly. Creates an Admin object and transfers it to the contract creator. Adding to the Pool (addCoinToGamePool) Takes a specified amount from the admin’s in_coin. Uses assert! to ensure the coin has sufficient value. Splits the amount from in_coin’s Balance and merges it into the game’s pool_amount. Outcome: Win: If the guess matches the roll, a reward equal to the bet is taken from the pool and merged into the player’s in_coin. Lose: If incorrect, the bet is deducted from in_coin and added to the pool via addCoinToGamePool.
- Sui
- Move
1 How to transfer Sui-based Wormhole to an exchange?
I'm trying to transfer a Sui-based Wormhole from my Sui wallet to another exchange. I attempted to swap through Suivision, but the slippage is too high right now. Are there any alternatives to convert or transfer without using the Suivision Swap process?
- Sui
- Architecture
02- Expert Q&A
ForPeera MetaMar 06, 2025Counter.sol not found in Openzeppelin Contracts
lib/openzeppelin-contracts/contracts/utils/Counters.sol": No such file or directory (os error 2)
- discussion
- expert q&a
02
- 2565
- 1780
- 402
- 397
- 369
- 328
- 283
- 278
- 275
- 271