Suiのステーブルコイン送金について整理しました！ ひとことで言うと、USDCなどの対応ステーブルコインを送るときに、送信側がSUIを持っていなくても送れるようにする仕組みです 普通の人からすると「ドルを送りたいだけなのに、なぜ別のトークンが必要？」という部分が大きな摩擦でした 技術的にはアドレス別残高と、条件を満たす送金用PTBがポイントです 何でも無料ではなく、対応銘柄・対応操作に絞ってガス代0にする設計です🚀 画像でざっくり整理しました🍙 #Sui #SuiDevTips

SuiのPayment Intents、支払いUXを考えるうえでかなり重要なので整理しました！ ひとことで言うと、スワップ・預け入れ・送金みたいな複数の操作を、1回の署名でまとめて実行する考え方です 途中だけ成功してしまう状態を避けやすく、アプリ側がガス代を持つ設計とも相性がいいです🚀 SuiのPTBらしさがかなり出ている部分なので、オンチェーン金融や決済系のアプリを作る人は見ておきたいところ👀 画像でざっくり整理しました🍙 #Sui #SuiDevTips

SuiのSIP-39、かなり重要なので整理しました！ ひとことで言うと、バリデータ参加に必要だった「30M SUI」という固定条件をやめて、ネットワーク全体のステーク量に応じた投票力ベースへ変える話です 目安としては 30M SUI から約 2.4M SUI へ。 それでも簡単な金額ではないですが、独立した運営者やチームが参加を考えやすくなるのは大きいです🚀 コミュニティでも、分散化が進むことへの期待や「やっと参加を考えられる」という反応がかなり多め👀 一方で、実際にバリデータ数がどれくらい増えるか、性能や運用品質を保てるかは引き続き見たいところです 画像でざっくり整理しました🍙 github.com/MystenLabs/sui/re… #Sui #SuiDevTips

Suiドキュメント更新 📝 (更新日: 2026-05-08) Sui Stackに、Walrus SitesとSuiNSの新しいガイドが追加されています Sui Moveの入門後に、実際のアプリや公開サイトへどうつなげるかを見る内容としてかなり良い更新 ✅ Walrusへ静的サイトをデプロイ・更新 ✅ SuiNSで読めるURLを付与 ✅ 名前解決・逆引き・サブネーム / Enoki API連携 特に、Walrusでサイトを置き、SuiNSで人間が読める名前を付ける流れが一通りまとまったのはありがたいです 単に機能を知るだけではなく、「Sui上でユーザーに見える体験をどう作るか」まで考えやすくなっています これまで個別に追う必要があった、公開サイト、名前解決、ユーザー識別の話が同じ文脈で読めるので、Suiのアプリ開発でウォレットアドレスやオブジェクトIDをそのまま見せない設計をしたい人には参考になりそうです github.com/MystenLabs/sui/co… #Sui #SuiDevTips #Walrus

Walrus ProtocolのSessions Round 2が本格始動！🦭 コミュニティみんなで「本当に使えるフィードバックツール」をWalrusネイティブで作るコンペが開催中です🚀 ✅作るもの ・誰でも簡単にフォーム作成できるプラットフォーム ・バグ報告・機能リクエスト・アンケート対応 ・提出データは全部Walrus保存＋Sealで暗号化 💸賞金総額 $1,500 WAL
 ⏰締切：5月18日 21:00（日本時間） 詳細・応募方法は引用スレッドをチェック！ 
作ったツールは今後のSessionsで実際に使われる可能性も？👀 興味ある人はリポスト＆チャレンジしてみて〜
参加したらぜひ教えてください！ #Walrus #Sui #SuiDevTips

codegenはSuiでdApp開発するときの肝になるライブラリだと思っています👀 以前 @mysten/codegen について記事を書いたんですが、そのときは v0.4.0 時点でした 改めて最新版を見てみると、型安全性や package ID 管理まわりがかなり実戦向けに進化していて、Sui dApp 開発ではちゃんと押さえておきたいところです！ 画像でざっくり整理しました🍙 #Sui #SuiDevTips

Sui Overflow 2026、いよいよ始まりますね！いまのうちに事前登録しておきましょう！ 今回はいまSui dApp開発で押さえておきたい Sui Stack 2026 を4枚で整理しました🍙 Frontend / Move / Package管理 / Data Access / Extensions あたりを、今の推奨に寄せてざっくりまとめています #Sui #SuiDevTips

OpenZeppelinの最近のSui向けの動きを整理しました！ #Sui #SuiDevTips 個人的に重要だと思うのは、 単にMove向けライブラリを出しただけでなく、 ✅Access / Math などの再利用部品 ✅Capabilityベースの設計 ✅PTB構築を含む実装例 ✅Oracle連携を含む end-to-end な参考実装 まで見せ始めていること Marketplace Reference Build の動画内容もあわせて、4枚にまとめました🍙

Suiでビルドする体験が他と違う理由、Quentinさんのハッカソン記事を読んで改めて実感しました！ ちなみにFaucet枯渇問題はあるあるなので、困っている人がいたらSutilsを紹介してあげてください🍙 sutils.vercel.app/faucet #Sui #Move #SuiDevTips ポーランドのWrocław X Warsawハッカソンで、ベテランデベロッパーたちのSui Move初体験の感想がまとめられていて、Suiの強みが鮮やかに浮かび上がっています 統一スタックが秀逸🚀 Sui Stackを使えば、複雑なdAppをデフォルトで安全に素早く構築でき、DeepBookやNavi、SuiLendなどの既存プロトコルを組み合わせやすい また、PTBsで連携がしやすく、DeFiポジションのオブジェクト転送がDAO管理を格段に楽に Moveのオブジェクトモデルも直感的とのこと！ コインは現金のように、NFTは果物のように、Shared Objectは図書館の本のように、Admin Capは車の鍵のように扱える 言語が不正操作を防ぐ仕組みなので、他チェーン出身の方々が「ビジネスロジックに集中できる」と絶賛🤓 ・zkLoginではブロックチェーンを隠せて、Googleログインで非ククリプトユーザーも自然に利用可能 ・WalrusはSuiオブジェクトでストレージを管理し、Sealと組み合わせればWeb2級の分散体験を実現 課題として、テストネットのfaucet枯渇やRPCリミットなどが挙げられます。また、Seal/Nautilusの認知が広がれば、さらに可能性が広がりそうです💧

SuiのSIP-58について、非エンジニアの方にもわかりやすく解説します🍙 #SuiDevTips 現在Suiでは、$SUI トークンなどの資産を扱う際、オブジェクトとして個別に管理されているため、送金時にCoinをマージしたりスプリットしたりする手間が発生します これが原因で、ガスコストの上昇や取引の複雑化を招いていたりします SIP-58は、この問題を根本的に解決する提案です トークンの残高をアドレス直下のバランスとして管理する方式へ移行し、イーサリアム的なシンプルさを導入します これにより送金が大幅に容易になり、手数料低減、高速処理、無制限の並列実行が可能に。 ガス支払いも残高から直接行え、NFTなどの資産は従来のオブジェクトモデルを維持するため、Suiの強みは損なわれません 仕組みの要点は、取引時に「残高変更の予約」を発行するだけとし、後でネットワークがアキュムレーターで集約・確定する点。これにより同時取引の衝突を回避し、スムーズな処理を実現します 結果として、ウォレットやdAppの開発しやすさ、全体のユーザー体験が大きく向上するのだと思います🚀 進捗（2025年12月18日現在）：GitHubのPRはオープン状態で、Mysten Labsのエンジニアによるレビューが活発です。 最新の動きは昨日（12月17日）、提案者mystenmark氏がalex-mysten氏のコメント（後方互換性、パフォーマンステスト、設計のトレードオフなど）に対し詳細に回答しています パフォーマンス検証も計画中ですが、承認まではさらなる議論が必要です。重要なアップデートとして期待されています！ 詳細はこちら：github.com/sui-foundation/si… Suiの進化が楽しみですね✨

学び derived objectのkeyではプリミティブな値は使わず、常にネームスペースを設けましょう #SuiDevTips

あれ、しれっと"Payment Kit"なるSDKが誕生してるやん👀 Sui公式の「安全で標準化された決済フレームワーク」っぽい🚀 ドキュメントはこちら！ docs.sui.io/standards/paymen… 普通にMoveの勉強にもなりそう！あとで読む📝 #SuiDevTips

🚀 Suiを深く理解したい人に読んでほしい記事 「How Transactions Work on Sui」は、Suiのトランザクションが どのように作成・検証・承認・実行・記録されるかを 🎮 アーケードや☕ コーヒー購入の例えでやさしく解説しています！ #SuiDevTips Suiの特徴である“オブジェクト中心モデル”と“並列処理”の仕組みが なぜ速く、効率的で、NFTやゲーム、DeFiに強いのかが感覚的に理解できます🚀 特におすすめのポイント👇 ✅技術を日常の比喩で直感的に説明している ✅トランザクションの流れをステップごとに整理している ✅Suiのスピードと信頼性の根拠がつかめる 初心者から開発者まで、Suiの「なぜ速いのか？」を理解するのに最適な記事です！

【翻訳解説】EVMからMoveへ：Part 2 MoveやEVMの監査をしているVulSightの記事がわかりやすかったので、SolidityとMove(Aptos, Sui)の違いをわかりやすく整理しました 今回は「型と権限の仕組み（Abilities & Access Control）」を中心に、Moveの設計思想を解説します👇 #SuiDevTips 🧩 Moveの型システム は、Solidityとは異なり「所有権」を型レベルで表現します。 各structには「Move VMがその値に対して何をできるか」を制約するability（能力）が定義されています 主なアビリティは次の4つです⚔️ copy：値を複製できる drop：値を破棄できる store：グローバルストレージに保存できる key：アカウントやオブジェクトの下でアドレス指定して保存できる 🧱 NFTやCoinのようなリソース型には、あえて copy と drop がありません。 複製できず、また勝手に破棄もできません。 これにより「資産が誤って消える」ことや「コピーによる二重管理」を防ぎます。 もしdropを持たない値を処理せずにトランザクションが終了すると、Moveでは自動的にabort（中断）します。 これによりリソースの安全性が保証されます 🔍 監査時のポイント Move監査では「この型にこのアビリティを持たせるべきか？」を常に確認します。 特に、copyやdropを誤って付けてしまうとバグの原因になります。 また、Aptosでは関数がアクセスするリソース型をacquiresで明示し、 Suiでは引数のオブジェクトでアクセス範囲を定義します 🔐 アクセス制御の考え方 SolidityのようなmodifierやonlyOwnerはMoveには存在しません。 その代わりに、AptosとSuiでは異なる方法で権限を管理します 🟩 Suiでは「Capability」を使います たとえば以下のように、MintCapとBurnCapという権限トークンを1回だけmintし、 それを管理者アドレスに渡します。 ``` struct MintCap has key, store { id: UID } struct BurnCap has key, store { id: UID } ``` この2つのリソースを持つ者だけがmint()やburn()を呼び出せます。 他の人が同じ名前の構造体を作っても、型が異なるため実行は失敗します。 Moveでは型が厳密にチェックされるため、権限の偽装は不可能です 🕵️‍♀️ 監査では次の2点を確認します： これらのCapabilityは誰が持っているか？漏洩のリスクはないか？ 信頼できないコードが参照を取得できる可能性はあるか？ 🟦 Aptosではsignerで権限を確認します。 関数の最初の引数が&signerで、呼び出し元のアドレスと管理者アドレスを比較します。 EVMのmsg.senderチェックに近い方法なので、EVM開発者にも馴染みやすい設計です。 🚪 Moveのトランザクション構造 Moveでは暗黙のコールバックやdelegatecallは存在せず、 すべてが明示的なentry function呼び出しとして実行されます。 fallback()やreceive()もないため、制御フローが完全に可視化されます。 この仕組みにより、再入可能性などの脆弱性を大幅に減らせます 🧱 アップグレードの仕組み Aptos：モジュールの所有者がアップグレード可能ですが、互換性（レイアウト・API・アビリティ）を破るとVMが拒否します。 Sui：パッケージはデフォルトで不変です。 アップグレードには専用の権限とポリシー遵守が必要です。 Suiには次の4つのポリシーがあります👇 Immutable（変更不可） Dependency-only（依存のみ変更可） Additive（追加のみ許可） Compatible（互換性を保った変更） ✅ まとめ Moveは、型安全性・権限管理・実行構造のすべてを「明示的」に設計しています。 リソースがコピーも破棄もできない仕組み、権限をリソースとして表現する設計、 そして安全なアップグレードモデルにより、 Moveは「安全性を設計段階で保証する言語」になっています。

【翻訳解説】VMからMoveへ：Part 1 MoveやEVMの監査をしているVulSightの記事がわかりやすかったので、SolidityとMove(Aptos, Sui)の違いをわかりやすく整理しました👇 #SuiDevTips 💡 EVM（Solidity） は「コントラクト中心」 コードとデータが1つのコントラクトにまとまっており、 mapping(address => uint) のようにして残高を管理します。 つまり、1つのスマートコントラクトが中央台帳のような役割を持っている 🧱 Aptos Move は「アカウント中心」の設計 各アカウントが自分の CoinStore リソースを持ち、 残高はコントラクトではなく自分のアカウントストレージに保存されます。 送金は、Aliceのリソースから引き出してBobのリソースに入金するように行われます。 そのため、Solidityのような mapping は不要なる！ 🌊 Sui Move はさらに進化して「オブジェクト中心」の設計 すべてのデータが一意のID（UID）を持つオブジェクトとして存在します。 ユーザーの残高も「コインオブジェクト」として表され、 送金の際にはAliceのコインを分割し、新しいオブジェクトをBobに渡します。 Suiではアカウントがデータを“所有”しており、状態を直接持つ箱ではないのが特徴💪 ⚙️ 実行環境の違い EVMはアドレスを指定して動的に呼び出す仕組みを持ち、 delegatecall などの危険な低レベル呼び出しも可能です。 一方、Move VMでは呼び出し先がコンパイル時に固定され、 delegatecall や fallback は存在しません。 そのため、制御の流れが明示的で安全に保たれる 🏠 アカウントとコードの関係 Ethereumではアドレスがコードも資産も保持しますが、 Moveではコード（モジュール）はアドレスやオブジェクトに公開 (publish) されます。 状態はアカウントの中ではなく、リソースやオブジェクトとして管理されます。 このように、コードとデータが明確に分離されているのが特徴 🕵️‍♀️ 監査の観点の違い Solidityでは「他コントラクトとの呼び出し」や「再入可能性」を重点的に見ますが、 Moveでは「リソースが正しい所有者に発行されているか」や 「アクセス制御が適切か」を確認 ✅ まとめ Moveは、Solidityの柔軟だけれど危険なモデルを、 型安全で構造的に安全なリソースモデルに置き換えました。 コントラクト中心から、アカウント中心、そしてオブジェクト中心へ

🌊 Suiのデータアクセスが進化！ Suiはこれまで使われてきたJSON-RPCを段階的に廃止し、 gRPCとGraphQL RPCという新しい仕組みに移行します。 これは「Suiの中の情報をどう取り出すか」が根本的に変わる大きな転換です 具体的にどう変わるの？？ #SuiDevTips 🔽Sui開発者の @iv_dev3 さんの記事とベースに解説するよ🔽 ⚡ gRPCとは Google発の通信方式で、超高速・リアルタイム通信に強みがあります。 ブロックチェーン上の「動き」をそのまま追いかけたいときに最適 🟦 たとえば… ・DeFiやトレードボットなど、価格変動を即座に反映したいアプリ ・バリデータの状態をリアルタイムで監視するツール 👉 データを「一瞬で受け取る」用途にぴったりです。 ⚡️ GraphQL RPCとは Facebookが作ったクエリ言語を使い、必要な情報だけをピンポイントで取得できます。 複雑なデータも一度のリクエストで整理して受け取れるのが特徴です 🟦 たとえば… ・NFTマーケットやダッシュボード系アプリで取引情報やメタデータをまとめて表示したいとき ・分析ツールで履歴データを組み合わせたいとき 👉 見せ方やデータの整理を重視するアプリに向いています。 📅 今後の予定 2025年末までに両方が正式版へ 2026年4月にJSON-RPCは完全停止 Suiのデータレイヤーは、 「より速く・賢く・使いやすく」なる方向へ進化しています。 このアップデートは、次世代のWeb3アプリ基盤を支える大きな一歩です🚀

💧 Major Update to the Sui Coin Standard! With the new coin_registry module, token design on Sui has become more flexible and secure than ever! Based on pika’s post and the official docs👇 #SuiDevTips 🔹 1. Improved Handling of Mint Authority In the old design, if you burned the TreasuryCap to renounce minting rights, you also lost the ability to update metadata. The new standard separates supply control (mint/burn) from metadata management, achieving both security and convenience 👌 🔹 2. Centralized Token Information Token details like name, symbol, description, and icon are now managed together within the Currency struct. They can be safely updated using the MetadataCap, and you can even delete the Cap afterward to permanently lock the metadata 🔒 🔹 3. Permissionless Liquidity Pools Token information is automatically indexed in the coin_registry, allowing DEXs to initialize pools without any special permissions 💫 (Yes, this also makes use of the new derived objects feature!) Thanks to this redesign, token issuance, management, and trading on Sui are now more standardized and transparent than ever 🌊

💧 Sui Coin 標準が大幅アップデート！ 新しい coin_registry モジュールにより、トークン設計がより柔軟で安全に進化しました！ pikaさんの投稿とdocsを元に解説します👇 #SuiDevTips 🔹 1. Mint権限の扱いが改善 旧仕様では TreasuryCap を焼却して発行権を放棄すると、 メタデータ更新もできなくなる制約がありました。 新仕様では、供給管理（mint/burn）とメタデータ更新権限が分離可能に！ 安全性と利便性を両立👌 🔹 2. Token情報の一元化 トークンの名前・シンボル・説明・アイコンが Currency 構造体で統合管理され、 MetadataCap により安全に更新可。 更新後にCapを削除して永久ロックも可能です🔒 🔹 3. パーミッションレスな流動性プール トークン情報が coin_registry で自動的にインデックス化され、 DEX側で特別な許可なしにプールを初期化可能💫 （ここでは話題の派生オブジェクトも活用されてるよ！） この新設計により、Sui上のトークン発行・管理・取引が より「標準化」かつ「透明」な形に進化しました🌊

Sui Moveのvec_set, vec_map, table, table_vecっていまいち使い分けがわからんので特徴やユースケースをまとめてみた #SuiDevTips

Sui Move共有オブジェクトの設計について #SuiDevTips 🔽翻訳 Suiの利点のひとつは、多くの場合、アプリを複数の共有オブジェクトに負荷を分散するように設計できる点です。 私たちが構築中のプロトコルでも、このパターンを採用しています。 そのため、共有オブジェクトの輻輳（コンジェスチョン）を意識して設計すれば、問題を軽減したり、場合によっては完全に回避することも可能です（もちろんアプリの設計次第ですが）。 さらに、Suiは共有オブジェクトの輻輳やコンセンサス処理に関して多くの改良を進めており、こうした理論上の制約が実際の運用でどの程度問題になるのか、今後の検証が楽しみです。 🍙 Mysticeti V2とも関連ありそう？ Suiでは、共有オブジェクトの扱い方次第でスループットの設計余地が大きく変わります。 例えば、アプリ全体の状態を単一のshared objectに集約するのではなく、複数に分割して負荷を分散する設計も可能です。 このパターンを活用すれば、共有オブジェクトの輻輳を大幅に緩和、あるいは回避することができます。 Mysticeti V2がもうすぐ登場予定なので、この辺りに対するアプデにも期待大ですね！🚀