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.

IPFS

Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.

Walrus is a decentralized storage and data availability protocol designed specifically for large binary files, or "blobs"

Walrus

Move is an executable bytecode language used to implement custom transactions and smart contracts. 

Move

（p/s：那些 “web3 更新” 中没有一个能让你大吃一惊然后称之为 alpha 😮‍💨）
阅读完整文章：https://x.com/InternSui81687/status/1897309368644985108

你曾经在连锁店之间转移资产并感觉自己像印第安纳·琼斯一样躲避陷阱吗？是啊. 那是因为现在的互操作性 = 危险的桥梁 + 核心故障点. 

>伊卡说：“不，我们已经完成了. ”

他们正在构建一个无需信任、快速自动对焦且不会将钥匙交给任何人的系统. 它基于 Sui 构建，使用阈值加密和 2PC-MPC

在 [这里的视频]（https://ipfs-cdn.peeranha.io/QmWBduxmwvTYMwvMd88J6Zwbn5fr4PbTXx3UXPtxUeArmA）中，大卫·拉什（Ika的联合创始人）直言不讳地说出了每个人的想法：互操作性被打破了 AF. 而且，他们没有像大多数团队那样写另一篇 “我们需要解决方案” 的博客，而是花了两年时间邀请安全专家、人工智能书呆子和学者来真正建立一个解决方案. 他们想出了什么？一个使用2PC MPC和阈值加密的系统——花言巧语基本上意味着：你的密钥是你的，你的资产不会像2017年的圣诞礼物那样被重新包装，而且一切进展得都像地狱一样快. 


比如，Ika 不只是保护你的东西. 它以亚秒级的延迟完成交易，并且仍然保持去中心化. 同时，桥梁在这里需要8分钟，而你的灵魂只是为了确认互换. 

 他们在 Sui 的基础上建造了这个. 如果你到现在为止一直睡在 Sui 上，那次午睡就结束了. Sui 的以对象为中心的模型、极快的终结性和 Mysticeti Consensus（是的，这是一回事，不是虚构的）非常适合 Ika 想要做的事情. 大卫甚至表示，Sui的开发经验使其成为一个显而易见的选择——这在加密领域是罕见的好评，因为每种开发工具都像一本古老的卷轴. 

但是真正吸引我的是他们对用户体验的看法. 最好的加密货币？那种很无聊. 还不错，但以 “它能正常工作” 的方式来看. Ika 正在为一个你甚至不知道自己在做跨链事情的未来开枪. 没有弹出窗口，没有桥梁，没有假代币. 只需打开钱包，本地借出您的比特币，进行跨链交换，然后保持活力. 这就是我们一直在要求的，但不知何故忘记要求了. 

而且不要以为这只适用于德根兄弟. Ika使DAO、独立团队和企业能够推出自己的托管解决方案——比如 “Fireblocks 入门包”，但使用类固醇，而且实际上是可以访问的. 您不再需要50万美元的设置来构建安全基础设施. 只有 Sui、Ika 和一点勇气. 

哦，我们不要在比特币上睡觉. BTC多年来一直处于观望状态，就像那个拒绝加入游戏的家伙一样. 但是 Ika 正在让它可玩. DeFi 无需打包，无需移动——只需将其锁定为原生抵押品即可. 机构一定会喜欢它，因为它可以让他们保持合规和高效. 没有税收资金，没有监护陷阱. 只是资本畅通无阻地流动. 


因此，如果有人问你，“加密的下一步是什么？”不要给他们发一篇写着 “互操作性是未来” 的推文话题

(p/s: Not one of those “web3 updates” that give you 3 lines of fluff and call it alpha 😮‍💨)
Read full article: https://x.com/InternSui81687/status/1897309368644985108

You ever move assets between chains and feel like you’re Indiana Jones dodging traps? Yeah. That’s because interoperability right now = risky bridges + central points of failure.

> Ika says: “Nah, we’re done with that.”

They’re building a system that’s trustless, fast AF, and doesn’t give your keys to anyone. Built on Sui, it uses Threshold encryption and  2PC-MPC

In the  [video here](https://ipfs-cdn.peeranha.io/QmWBduxmwvTYMwvMd88J6Zwbn5fr4PbTXx3UXPtxUeArmA ), David Lash (co-founder of Ika) straight up says what everyone’s thinking: interoperability is broken AF. And instead of writing another “we need a solution” blog like most teams do, they spent two years pulling in security experts, AI nerds, and academics to actually build one. What they came up with? A system using 2PC MPC and threshold encryption — fancy words that basically mean: your keys stay yours, your assets don’t get rewrapped like a Christmas gift from 2017, and everything moves fast as hell.


Like, Ika doesn’t just secure your stuff. It rips through transactions at sub-second latency and still stays decentralized. Meanwhile bridges are out here taking 8 minutes and your soul just to confirm a swap.

 They built this on Sui. And if you’ve slept on Sui until now, that nap is over. Sui’s object-centric model, blazing-fast finality, and Mysticeti Consensus (yes that’s a thing, no it’s not made up) are perfect for what Ika’s trying to do. David even said Sui’s dev experience made it an obvious choice — which is rare praise in crypto where every dev tool feels like an ancient scroll.

But what really got me was their take on UX. The best crypto? The kind that’s boring. Not in a bad way, but in the “it just works” kinda way. Ika’s shooting for a future where you don’t even know you’re doing cross-chain stuff. No popups, no bridges, no fake tokens. Just open your wallet, lend your BTC natively, do a swap across chains, and keep vibin’. That’s what we’ve been asking for and somehow forgot to demand.

And don’t think this is just for degen bros. Ika enables DAOs, indie teams, and businesses to roll out their own custody solutions — think “Fireblocks starter pack” but on steroids and actually accessible. You don’t need a $500k setup to build secure infra anymore. Just Sui, Ika, and a little bit of courage.

Oh, and let’s not sleep on Bitcoin. BTC’s been sitting on the sidelines for years like that dude who refuses to join the game. But Ika’s making it playable. DeFi with no wrapping, no moving — just lock it as native collateral and go. Institutions are gonna love it because it keeps them compliant and efficient. No tax FUD, no custodial traps. Just capital flowing clean.


So if someone asks you, “What’s next for crypto?” don’t send them a tweet thread that says “Interoperability is the future"

What is IKA? “Not just the hype 👀”

IKA 是什么？“不只是炒作 👀”

嘿，我正在考虑作为验证者将我的 SUI 原生质押到 Mysten Labs. 我想知道我是否有可能以这种方式蒙受损失，而且，这些资金是否严格用于安全目的，而不是协议中的流动性？把它放在冷钱包里会更安全吗？

Hey, I'm considering doing native staking of my SUI to Mysten Labs as a validator. I'm wondering if there's any chance I could lose money this way, and also, are these funds strictly used for security purposes and not for liquidity in the protocol? Would it be safer to just keep it in a cold wallet?

Is it safe to stake SUI with Mysten Labs as a validator?

使用 Mysten Labs 作为验证者质押 SUI 是否安全？

I'm having trouble setting up a full node on the Walrus network. Could someone guide me on how to run a full node, including any necessary configurations and dependencies?

How to run a full node on Walrus network?

I'm building a content posting platform called Scribe, where users can write and post content. Currently, when I publish blobs using CLI, my address is the owner. However, when using Node.js, the publisher's address becomes the owner. Is there a way to maintain ownership of blobs published through Node.js?

How to keep blob ownership when using Node.js for publishing?

我在正确的网络上将泰达币从币安转移到了Sui，但金额没有记入账户. 有什么办法可以收回这些资金吗？

I transferred USDT from Binance to Sui on the right network, but the amount was not credited. Is there any way to recover these funds?

Sent USDT from Binance to Sui, but not credited

从 Binance 向 Sui 发送了 USDT，但未记入账户

我一直在使用Sui桥来转移一些ETH，但由于费用很高，还没有申领. 如果我让它无人认领，会发生什么？

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?

What happens if I don't claim ETH via Sui bridge?

如果我不通过 Sui bridge 申领 ETH 会怎样？

我知道 solidity 并且已经在上面做了一些项目，我想知道在更短的时间内... 比如不到一个月的时间我就能轻松学习 Move 吗？

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?

Is it easy to learn Move after solidity?

学习 Solidity After Move 很容易吗？

各位我想知道在 sui 上制作游戏、nft 市场、dex 等去中心化应用服务是否有利可图？另外，部署成本大概是多少？

Guys I was wondering if it was profitable to make dapps services like games, nft marketplaces, dex on sui?Plus how much cost rouphly would that be to deploy?

Is it profitable to make dapps services (like games ) on sui?

在 sui 上制作 dapps 服务（如游戏）有利可图吗？

伙计们我想在 sui 上做 dapp 想知道���没有人能给出学习动作的最佳场所

Guys I want to make dapps on sui and was wondering if anyone can give the best place to learn move lang

Best place to learn Move for beginners?

初学者学习动作的最佳去处？

伙计们，我想知道 sui 上的 nft 是否具有与 EVM 链中相同的功能和工作方式. 他们也能成为自建的 NFT 市场吗？

Guys I was wondering if the nfts on sui have the same features and work the same way as in EVM chains. And can their be NFT marketplace built in sui too?

How does NFT work on sui?

NFT 在 sui 上是如何运作的？

各位我对 sui 很陌生，想知道 sui 上是否有代币系统？就像 solana 上的 pump.fun 系统一样，如果能加入 sui 就好了... 由于 sui 的速度很快，那就更好了. 请发送该网站的链接，并说明在sui上购买/出售或制作代币需要多少美元. 
谢谢你

Guys I am very new to sui and was wondering if there was a token system ob sui? Just like pump.fun system on solana it would be great to have in sui... it would be better due to high speed of sui. Please send the link of the website and genrally how much $ it takes to buy/sell, or make a token on sui.
ThankYou

Pump.fun on sui?

pump.fun on sui？

如何在 Sui 中实现 NFT，即使在 NFT 被共享或转让给其他用户之后，原始铸币商仍保留对铸造、更新和销毁 NFT 的完全控制权（所有权）？我希望共享用户只能查看和转移NFT，而不能修改或销毁它. 我可以遵循特定的设计模式或模块来在 Sui 中实现这种行为吗？

How can I implement an NFT in Sui where the original minter retains full control (ownership) over minting, updating, and burning the NFT, even after the NFT is shared or transferred to other users? I want the shared users to only be able to view and transfer the NFT, but not modify or destroy it. Is there a specific design pattern or module I can follow to achieve this behavior in Sui?

hello community 

你好社区 

# 👀 SEAL 已在 Sui 测试网上线 — 我认为 Web3 数据隐私即将改变

在 Web3 中，经常会听到诸如**“用户拥有自己的数据”**或**“通过设计去中心化”**之类的短语. 但是，仔细观察，许多应用程序仍然依赖集中式基础设施来处理敏感数据——使用 AWS 或 Google Cloud 等服务进行密钥管理. 这就引入了一个矛盾：表面上的去中心化，底层的集中化. 


但是，如果有一种方法可以在不放弃权力下放的情况下安全地管理机密呢？介绍 SEAL — 去中心化机密管理 (DSM)，现已在 Sui 测试网上线. SEAL 旨在修复 Web3 最大的虚伪之处之一：在秘密使用 AWS 的同时大声疾呼去中心化

![](https://ipfs-cdn.peeranha.io/QmcRWFsXzUBecBmZBzVPMdtSS9zqA4yJMysXhPdYhE3bWK)

# 你可能会问我：海豹突击队是什么？

SEAL 是一种协议，可让您安全、**分散地**管理敏感数据——专为 Web3 世界构建. 可以将其视为插入 dApp 的隐私优先访问控制层. 



您可以将 SEAL 视为一种可编程的数据锁. 你不只是手动锁定和解锁，而是使用Move on Sui**将策略直接写入智能合约**. 

假设你正在构建一个 DApp，其中：

-只有 NFT 持有者才能解锁高级教程
-或者，在泄露敏感文件之前，DAO 可能必须进行投票
-或者你想对元数据进行时间锁定并且只能在特定日期之后访问

海豹突击队使所有这些成为可能. 访问控制*在链上* 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 

海豹突击队使所有这些成为可能. 访问控制*在链上* 运行，完全自动化，无需管理员进行管理. 只是逻辑，直接融入区块链. 

另一个有趣的文章是SEAL如何处理**加密**. 它使用所谓的**阈值加密**，这意味着：没有一个节点可以解密数据. 需要一组服务器才能协同工作——有点像多重签名，但用于解锁机密. 这样可以分配信任，避免常见的单点故障问题. 

为了保证信息的真正私密性，SEAL 会加密和解密**客户端**的所有内容. 任何后端都看不到您的数据. 从字面上看，它会留在你的手中，放在你的设备上. 

而且 SEAL 不在乎你在哪里存储数据. 无论是 IPFS、Arweave、Walrus 还是其他平台，SEAL 都不会试图控制这部分. 它只关注**谁可以看到什么**，而不是*东西的存储位置*. 

>所以是的，它不仅仅是一个库或 API，它是 dApp 的**���上优先、访问控制、默认隐私层**. 


![](https://ipfs-cdn.peeranha.io/QmPTLrU3XXDG3zx92LXhh8GzdRgUG98rPb8ZkX42nUf77S)


**SEAL 填补了一个非常关键的空白**. 让我们再分解一下.  

---

如果你正在构建一个处理**任何形式的敏感数据**（封闭内容、用户文档、加密消息，甚至是锁定时间的 NFT 元数据）的 dApp，你也会遇到同样的问题：

➡️ 如何在不依赖集中服务的情况下安全地管理访问权限？

如果没有像海豹突击队这样的队伍，大多数队伍都会：

1. 使用 AWS KMS 或 Firebase 等集中式工具，这显然与去中心化背道而驰
2. 或者尝试自己修补半生不熟的加密逻辑，这些逻辑通常会变得脆弱且难以审计

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

这两个比例都不好. 尤其是在你尝试跨多个链或社区构建无需信任的应用程序时. 

**SEAL 使整个过程模块化和可编程. **

您可以在Move智能合约中定义访问规则，SEAL会处理其余的——密钥生成、解密批准和访问强制执行——所有这些都无需任何人手动颁发密钥或进行后端检查. 

更好的是，这些规则是**可审计和不可改变的**——一旦上链，它们就会遵循合同，而不是人工管理员. 

因此，与其问 “谁应该管理对这些数据的访问权限？”你只要问：

>“应该用什么逻辑来定义访问权限？”
> >... 然后让链条来处理. 简洁且可扩展. 

这就是SEAL不仅仅涉及 “安全工具” 的原因——它是**任何关心隐私、合规性或动态访问逻辑的DApp的基础层. **

这是一个很小的转变——但它改变了我们对 Web3 中数据的看法. **与其在部署后进行加密，或依赖外部服务，不如从内置隐私开始——访问权限完全由智能合约逻辑处理. **

而这正是 Web3 现在需要的. 

---
# SEAL 实际上是如何运作的？
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

我们已经介绍了**什么是 SEAL**以及**为什么 Web3 需要它**，让我们来看看它在幕后是如何构建的. 这部分是技术性更强的地方，但还是不错的. 一旦你看到所有部分是如何组合在一起的，建筑就会变得很优雅. 

总体而言，SEAL的工作原理是使用一种名为**基于身份的加密（IBE）**的技术，将**链上访问逻辑**与**链下密钥管理**相结合. 这允许开发人员将数据加密为*身份*，然后依靠智能合约来定义*允许谁*对其进行解密. 

## 步骤 1：智能合约中的访问规则（在 Sui 上）

一切都从智能合约开始. 当你使用 SEAL 时，你需要在你的 Move 合约中定义一个名为 seal_approve 的函数，你可以在这里写下解密条件. 

例如，以下是用 Move 编写的简单时间锁定规则：

```rust
entry fun seal_approve(id: vector<u8>, 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);
}
```

一旦部署，该合约将充当看门人. 每当有人想要解密数据时，他们的请求都会被根据这个逻辑进行检查. 如果通过，密钥将被释放. 如果没有，他们就会被封锁. 没有人需要干预. 

##**步骤 2：基于身份的加密 (IBE)**

这就是魔法发生的地方. 

SEAL 没有加密特定钱包地址（如 PGP 或 RSA）的数据，而是使用**身份字符串**——这意味着你可以加密成类似的内容：

-0x 钱包地址
-dao_voted: proposal_xyz
-pkgid_2025_05_01（基于时间戳的规则）
-甚至是 game_user_nft_holder

当数据加密后，它看起来像这样：

```rust
Encrypt(mpk, identity, message)
```

-mpk = 主公钥（众所周知）
-身份 = 逻辑定义的收件人
-消息 = 实际数据

之后，如果有人想解密，密钥服务器会检查他们是否符合政策（通过链上的 seal_approve 调用）. 如果获得批准，它将返回该身份的派生私钥. 

```rust
Derive(msk, identity) → sk  
Decrypt(sk, encrypted_data)
```

然后，用户可以在本地解密内容. 

因此，无需提前知道*谁*将解密即可完成加密. 您只需定义*条件*，SEAL 稍后再计算其余部分. 它是动态的. 


##**第 3 步：密钥服务器 — 脱链，但未集中化**

你可能想知道：谁在拿着这些万能钥匙？

这就是 SEAL 的**密钥服务器**的用武之地. 可以把它看作是一个后端：

-持有主密钥 (msk)
-关注链上合约（比如你的 seal_approve 逻辑）
-仅在满足条件时才发出派生密钥

但是——这是关键——海豹突击队不只依赖*一台*密钥服务器. 你可以在**阈值模式**下运行它，在发放解密密钥之前，需要多个独立服务器达成一致. 

例如：五分之三的密钥服务器必须批准请求. 这避免了中心故障点，也允许在密钥管理层进行权力下放. 

更好的是，将来SEAL将支持**MPC（多方计算）**和**基于飞地的设置**（例如TEE），因此您可以在不影响可用性的情况下获得更强的保障. 

##**步骤 4：客户端解密**

将密钥返回给用户后，实际的解密将在用户的设备上进行**. 这意味着：

-服务器永远看不到你的数据
-后端从不存储解密的内容
-只有用户可以访问最后的消息

这是一个可靠的隐私模型. 即使有人破坏了存储层（IPFS、Arweave 等），如果不传递访问逻辑，他们仍然无法读取数据. 

以下是快速思维模型：

![](https://ipfs-cdn.peeranha.io/Qmcni3mRP85eLrfcny1ZgDdeQbe3rj9CdD2y6zHvzyZAS3)

这种结构使您可以轻松构建访问规则不是硬编码的去中心化应用程序，它们是动态的、可审计的，并且完全集成到您的链逻辑中. 

##**SEAL 背后的团队**

SEAL 由区块链安全社区的知名人物**Samczsun**领导. 他曾是Paradigm的研究合伙人，曾审计过多个生态系统并将其从重大漏洞中拯救出来. 现在，他全职致力于将 SEAL 建成 Web3 隐私基础设施的核心部分. 

凭借他的背景和信誉，SEAL 不仅仅是另一个实验工具，它是一次严肃的尝试，旨在使去中心化数据隐私既实用又可扩展. 

随着 SEAL 在 Sui 测试网上线，它为 Web3 应用程序如何管理机密带来了新的标准. 通过结合链上访问控制、阈值加密和客户端隐私，SEAL 为去中心化数据处理提供了更值得信赖的基础. 

无论你是在构建 dApp、DAO 还是去中心化游戏，SEAL 都提供了一个强大的工具包，可以在不影响去中心化的前提下执行访问控制和保护用户数据. 

如果 Web3 要向前发展，像 SEAL 这样的安全基础设施不是可选的——这是必不可少的

# 👀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

![](https://ipfs-cdn.peeranha.io/QmcRWFsXzUBecBmZBzVPMdtSS9zqA4yJMysXhPdYhE3bWK)

# 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.


![](https://ipfs-cdn.peeranha.io/QmPTLrU3XXDG3zx92LXhh8GzdRgUG98rPb8ZkX42nUf77S)


**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:

1. Use centralized tools like AWS KMS or Firebase, which clearly goes against decentralization
2. 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?
![](https://ipfs-cdn.peeranha.io/QmRsHK6qzzjcQsZcTdgMBiQdn4QZzSaBRSpM5ZdgXrH9gw)

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:

```rust
entry fun seal_approve(id: vector<u8>, 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:

```rust
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.

```rust
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:

![](https://ipfs-cdn.peeranha.io/Qmcni3mRP85eLrfcny1ZgDdeQbe3rj9CdD2y6zHvzyZAS3)

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

👀 SEAL- I Think Web3 Data Privacy Is About to Change

👀 SEAL-我认为 Web3 数据隐私即将改变

这是 “Sui Move 中的亲子对象” 系列的第 3 部分. 

有时，您的父类型和子类型是在不同的模块甚至不同的包中定义的. 例如，您可能有一个可以存储任何类型的 Parcel 对象的通用仓库对象. 仓库模块想要提取一个包裹子节点，但是包裹类型是在其他地方定义的. 在这种情况下，我们使用 transfer:: public_receive，它是 receive 的跨模块表兄弟. 

###**接收 vs public_receive**

正如我们所见，transfer:: receive <T>只能在定义 T（或朋友）的模块中调用，因为它不需要 T: store. Move 字节码验证器实际上确保在任何要接收的调用<T>中，T 类型来自当前模块. 这是对仅限钥匙的对象的安全限制. 

transfer:: public_receive <T>是一个变体，它*需要* T: key + store，但允许在 T 的模块之外接收. 换句话说，如果对象类型具有存储能力（这意味着它可以自由存在于全局存储中），则任何模块（给定父模块的 &mut UID）都可以使用 public_receive 接收它. 这非常适合父模块与子模块不同的情况. 

为什么需要商店？因为存储标志着该对象可以安全地保存并在其定义模块之外传递. 仅限密钥的对象可能具有原始模块希望在传输/接收时强制执行的自定义不变量；通过排除public_receive中的那些不变量，Sui会强制开发人员在模块内处理它们（正如我们将在灵魂绑定对象中看到的那样）. 如果一个对象有存储，则更宽松，而且 Sui 允许使用通用的传输/接收逻辑在外部对其进行管理. 

###**示例：分离父模块和子模块**

让我们用一个简单的场景来说明一下：一个存储 Parcel 对象的仓库. 包裹类型在自己的模块中定义，仓库在另一个模块中定义. 我们将展示仓库如何使用 public_receive 接收子包裹. 

```rust
module demo::parcel {  // Child module
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    /// A parcel object that can be stored in a Warehouse.
    /// It has both key and store, so it can be transferred across modules.
    struct Parcel has key, store { id: UID, contents: vector<u8> }

    public entry fun create_parcel(contents: vector<u8>, ctx: &mut TxContext): Parcel {
        Parcel { id: object::new(ctx), contents }
    }
}
```

```rust
module demo::warehouse {  // Parent module
    use sui::transfer::{Self, Receiving, public_receive};
    use demo::parcel::{Self, Parcel};
    use sui::object::{UID};
    use sui::tx_context::{Self, TxContext};

    struct Warehouse has key { id: UID, location: address }

    public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse {
        Warehouse { id: object::new(ctx), location }
    }

    /// Receive a Parcel that was sent to this Warehouse. 
    /// Returns the Parcel to the caller (transferred to caller's address).
    public entry fun withdraw_parcel(
        warehouse: &mut Warehouse, 
        parcel_ticket: Receiving<Parcel>, 
        ctx: &mut TxContext
    ): Parcel {
        // Using public_receive because Parcel is defined in another module and has store
        let parcel = public_receive<Parcel>(&mut warehouse.id, parcel_ticket) [oai_citation_attribution:27‡docs.sui.io](https://docs.sui.io/concepts/transfers/transfer-to-object#:~:text=%2F%2F%2F%20Given%20mutable%20,argument) [oai_citation_attribution:28‡github.com](https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T);
        // Transfer the parcel to the transaction sender (so the caller gets ownership)
        transfer::transfer(parcel, tx_context::sender(ctx));
        // We return nothing because we've transferred the Parcel out to the caller.
    }
}
```

让我们分解一下 redath_parcel 中发生了什么：

-我们打电话给 public_receive <Parcel>(&mut warehouse.id, parcel_ticket)由于 Parcel 具有存储能力，因此即使我们不在包裹模块中，也允许此调用. 在幕后，它会执行与接收相同的检查和提取，但允许跨模块进行检查，因为存储表明这样做是安全的. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T
-然后，我们会立即将收到的包裹转到来电者的地址（tx_context:: sender（ctx））. 此步骤可确保包裹离开仓库并交给发起提款的用户. 我们也可以直接从函数中返回 Parcel，然后 Sui 会将其视为由调用者地址拥有的输出（因为它是输入函数的输出）. 进行显式传输更为冗长，但可以清楚地说明发生了什么（并允许我们在释放对象之前进行任何检查）. 

**为什么要在包裹中加入店铺？**如果 Parcel 缺乏存储能力（即只有密钥），则 <Parcel>demo:: warehouse 中的 public_receive 调用将无法编译 — Sui 强制要求 T 为 public_receive 存储. 在这种情况下，我们将被迫在包裹模块本身中使用接收功能（或使用某种朋友关系）来取回包裹，这会使跨模块的设计变得复杂. 通过在 Parcel 中添加存储，我们实际上是在说 “这个对象可以自由移动和被外部模块接收”，这正是我们想要的通用容器模式. 

**函数调用模式：**要在交易中使用它们，流程为：

1. **存款（转移到对象）：**致电转移:: public_transfer（parcel_obj，@warehouse_id）将包裹发送到仓库. 这会将包裹的所有者标记为仓库. （我们在这里使用 public_transfer 是因为它在 Parcel 模块之外，而且 Parcel 有存储. 在包裹模块内，普通的传输也可以. ）
2. <Parcel>**提款（收回）：**稍后，致电撤回包裹（warehouse_obj，接收（包裹编号，...））. <Parcel>SDK 可以通过引用包裹的 ID 和最新版本来获取接收信息. 该函数将调用 public_receive 然后将包裹转移给你. 

在拨打 redth_parcel 电话后，包裹的所有者回到了一个地址（你的），所以它又是一个普通的地址拥有的物品. 仓库不再拥有它. 

**跨模块注意事项：**请注意，仓库模块需要了解包裹类型（我们使用 demo:: parcel:: Parcel）. 这是因为我们将接收明确键入为接收<Parcel>. 如果你想要一个可以接收任何类型对象的真正通用容器，你必须使用泛型或其他方法（可能是带有类型擦除的动态字段）. 但是对于大多数用例，你会知道你期望的是什么类型的孩子. 

**为什么 public_receive 而不只是调用 receive？**如果我们尝试在<Parcel>仓库模块中转移:: 接收（&mut warehouse.id，parcel_ticket），则移动验证器会拒绝，因为在 demo:: warehouse 中没有定义包裹. Sui 提供了 public_receive 作为通过额外能力检查（需要存储）来实现此目的的好方法. 同样，Sui 也有传输与 public_transfer、freeze_object 与 public_freeze_object 等，遵循相同的模式：public_ 版本在定义模块之外使用，需要存储. 

**别忘了家长的许可：**即使有 public_receive，你仍然需要那个 &mut warehouse.id. 我们之所以得到它，是因为撤回包裹在 Warehouse 的模块中并接受 &mut Warehouse. 因此，只有可以这样称呼的人（仓库的所有者）才能提取包裹. 如果仓库模块没有公开提供这样的函数，那么也没有人可以在外部对其子模块调用 public_receive. 因此，跨模块不会绕过父级的控制；它只允许父级的代码处理其未定义类型的子类型. 

**关于存储能力的说明：**提供对象存储可以使其更加灵活，但限制稍微减少一点——任何具有父引用的模块都可以使用 public_receive 将其拉出. 如果你想**限制**对象的检索方式（例如，强制执行自定义逻辑或防止轻松提取），你可以故意将其设为仅限密钥. 我们将用灵魂束缚的物体来看这个例子. 在这种情况下，你可以实现自定义接收函数，而不是依赖 public_receive. 

总结一下这部分：public_receive 是你管理其他模块中定义的子对象的好友，只要这些对象具有存储能力即可. 它允许您构建跨模块系统（例如我们的仓库/包裹），同时仍然尊重所有权和访问控制. 只要记得在子类型上添加存储，并在从模块外部将它们发送给父类型时使用 public_transfer 即可. 
![](https://ipfs-cdn.peeranha.io/Qmf1MyZ4w8CitW3trDgmr5YWZgMYnmNvVBiFVBqsLYCo45)

This is the part 3  of "Parent-Child Objects in Sui Move" series.

Sometimes your parent and child types are defined in different modules or even different packages. For example, you might have a generic Warehouse object that can store any kind of Parcel objects. The Warehouse module wants to pull out a Parcel child, but the Parcel type is defined elsewhere. In such cases, we use transfer::public_receive, which is the cross-module cousin of receive.

### **receive vs public_receive**

As we saw, transfer::receive<T> can only be called in the module that defines T (or a friend) because it doesn’t require T: store . The Move bytecode verifier actually ensures that in any call to receive<T>, the type T is from the current module . This is a safety restriction for key-only objects.

transfer::public_receive<T> is a variant that *requires* T: key + store but allows receiving outside T’s module . In other words, if the object type has the store ability (meaning it’s allowed to exist in global storage freely), then any module (given a &mut UID of the parent) can receive it using public_receive . This is perfect for cases where the parent’s module is different from the child’s module.

Why require store? Because store marks that the object can be safely persisted and passed around outside of its defining module. Key-only objects might have custom invariants that the original module wants to enforce on transfer/receive; by excluding those from public_receive, Sui forces developers to handle them in-module (as we’ll see with soul-bound objects). If an object has store, it’s more permissive, and Sui allows generic transfer/receive logic to manage it externally ￼.

### **Example: Separate Parent and Child Modules**

Let’s illustrate with a simple scenario: a Warehouse that stores Parcel objects. The Parcel type is defined in its own module, and the Warehouse in another. We’ll show how Warehouse can receive a Parcel child using public_receive.

```rust
module demo::parcel {  // Child module
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    /// A parcel object that can be stored in a Warehouse.
    /// It has both key and store, so it can be transferred across modules.
    struct Parcel has key, store { id: UID, contents: vector<u8> }

    public entry fun create_parcel(contents: vector<u8>, ctx: &mut TxContext): Parcel {
        Parcel { id: object::new(ctx), contents }
    }
}
```

```rust
module demo::warehouse {  // Parent module
    use sui::transfer::{Self, Receiving, public_receive};
    use demo::parcel::{Self, Parcel};
    use sui::object::{UID};
    use sui::tx_context::{Self, TxContext};

    struct Warehouse has key { id: UID, location: address }

    public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse {
        Warehouse { id: object::new(ctx), location }
    }

    /// Receive a Parcel that was sent to this Warehouse. 
    /// Returns the Parcel to the caller (transferred to caller's address).
    public entry fun withdraw_parcel(
        warehouse: &mut Warehouse, 
        parcel_ticket: Receiving<Parcel>, 
        ctx: &mut TxContext
    ): Parcel {
        // Using public_receive because Parcel is defined in another module and has store
        let parcel = public_receive<Parcel>(&mut warehouse.id, parcel_ticket) [oai_citation_attribution:27‡docs.sui.io](https://docs.sui.io/concepts/transfers/transfer-to-object#:~:text=%2F%2F%2F%20Given%20mutable%20,argument) [oai_citation_attribution:28‡github.com](https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T);
        // Transfer the parcel to the transaction sender (so the caller gets ownership)
        transfer::transfer(parcel, tx_context::sender(ctx));
        // We return nothing because we've transferred the Parcel out to the caller.
    }
}
```

Let’s break down what’s happening in withdraw_parcel:

- We call public_receive<Parcel>(&mut warehouse.id, parcel_ticket). Because Parcel has the store ability, this call is allowed even though we’re not in the parcel module . Under the hood, this does the same check and extraction as receive, but it’s permitted cross-module since store indicates it’s safe to do so. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T
- We then immediately transfer the received Parcel to the caller’s address (tx_context::sender(ctx)). This step ensures the parcel leaves the warehouse and goes to the user who initiated the withdrawal. We could also have just returned Parcel from the function, and Sui would treat it as an output to be owned by the caller’s address (since it’s an entry function output). Doing an explicit transfer is more verbose, but makes it clear what’s happening (and allows us to do any checks before releasing the object).

**Why include store in Parcel?** If Parcel lacked the store ability (i.e. was only has key), the public_receive<Parcel> call in demo::warehouse would not compile – Sui enforces that T has store for public_receive . In that case, we’d be forced to retrieve the parcel using receive within the parcel module itself (or use some friend relationship), which complicates cross-module design. By adding store to Parcel, we effectively say “this object can be freely moved and received by external modules,” which is what we want for a generic container pattern.

**Function call pattern:** To use these in a transaction, the flow would be:

1. **Deposit (transfer to object):** Call transfer::public_transfer(parcel_obj, @warehouse_id) to send a Parcel into a Warehouse. This marks the parcel’s owner as the warehouse. (We use public_transfer here because it’s outside the Parcel module and Parcel has store . Inside the parcel’s module, a plain transfer would work too.)
2. **Withdraw (receive back):** Later, call withdraw_parcel(warehouse_obj, Receiving<Parcel>(parcel_id, ...)). The Receiving<Parcel> can be obtained by the SDK by referencing the parcel’s ID and latest version. The function will call public_receive and then transfer the parcel to you.

After the withdraw_parcel call, the parcel’s owner is back to an address (yours), so it’s a normal address-owned object again. The warehouse no longer owns it.

**Cross-module considerations:** Notice that the Warehouse module needed to know about the Parcel type (we use demo::parcel::Parcel). This is because we explicitly type the Receiving as Receiving<Parcel>. If you wanted a truly generic container that could receive any type of object, you’d have to use generics or a different approach (possibly dynamic fields with type erasure). But for most use-cases, you’ll know what types of children you expect.

**Why public_receive instead of just calling receive?** If we tried transfer::receive<Parcel>(&mut warehouse.id, parcel_ticket) in the warehouse module, the Move verifier would reject it because Parcel is not defined in demo::warehouse. Sui provides the public_receive as the blessed way to do this with an extra ability check (requiring store). Similarly, Sui has transfer vs public_transfer, freeze_object vs public_freeze_object, etc., following the same pattern: the public_ versions are for use outside the defining module and require store  .

**Don’t forget the parent’s permission:** Even with public_receive, you still need that &mut warehouse.id. We got it because withdraw_parcel is in Warehouse’s module and accepts &mut Warehouse. Thus, only someone who could call that (the warehouse’s owner) can withdraw the parcel. If the warehouse module didn’t provide such a function publicly, no one could externally call public_receive on its children either. So cross-module doesn’t bypass the parent’s control; it just allows the parent’s code to work with children of types it didn’t define.

**A note on store ability:** Giving an object store makes it more flexible but slightly less restricted – any module with the parent reference can pull it out using public_receive. If you want to **restrict** how an object is retrieved (for example, enforce custom logic or prevent easy extraction), you might deliberately make it key-only. We’ll see an example of that with soul-bound objects. In those cases, you might implement a custom receive function instead of relying on public_receive.

To sum up this part: public_receive is your friend for managing child objects defined in other modules, as long as those objects have the store ability. It allows you to build cross-module systems (like our Warehouse/Parcel) while still respecting ownership and access control. Just remember to include store on child types and use public_transfer when sending them to a parent from outside their module .
![](https://ipfs-cdn.peeranha.io/Qmf1MyZ4w8CitW3trDgmr5YWZgMYnmNvVBiFVBqsLYCo45)

Cross-Module Child Management with public_receive

使用 public_receive 进行跨模块儿童管理

Sui 生态系统中 AMM 机器人的主要特征和功能是什么？他们如何改进传统的交易机制，以及它们为在Sui网络上使用DeFi协议的用户提供了哪些优势？

例如，我需要建造一个还是可以使用 Turbos Finance

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

AMM Bot in Sui Ecosystem

Sui 生态系统中的 AMM 机器人

说实话，如果你曾经在**Sui**上构建过，你可能碰到了一些墙. 

从神秘的对象 ID 到兼顾 CLI 和启动本地网络，这就像在你编写第一行业务逻辑之前就为一场 boss 战斗做准备一样. 

![](https://ipfs-cdn.peeranha.io/Qma8QMuBADaXikAevRLHj9K5EMJ2AZypucXfVVrWxJSntd)

在最近作为 “溢出之路” 系列的一次研讨会上，来自Dubhe Foundation的Moven详细介绍了Dubhe Engine的工作原理、它解决了哪些问题，以及它如何不仅仅是一个工具——它是一个不断发展的运动. 

视频链接：https://www.youtube.com/watch?v=CHkOS-TYehM

# 问题：零散的工具，繁重的设置

Moven 以一些关于当前 Sui 开发格局的真实讨论拉开了序幕：

-新手面临着艰难的学习曲线：设置钱包、领取测试代币、脚手架包、学习 Move 语法、启动本地测试网、配置 SDK 等. 
-即使是经验丰富的开发人员也会发现自己将时间浪费在重复的设置任务上，而不是专注于实际的DApp逻辑. 
-代码库迅速变得单一——包含数据结构、构造函数、助手和输入函数的大型、混乱的 .move 文件都挤在一起. 

简而言之：生态系统发展迅速，但这些工具直到现在都没有跟上. 


##**解决方案：基于架构的代码生成**

**Dubhe Engine**的核心是一个关键思想：**架构优先开发**. 

只需一个配置文件 (d.config.ts)，开发人员就可以定义：

-他们的链上数据结构
-活动
-错误
-自定义类型（甚至是自定义结构的二维向量！）

然后，一个命令 (`pnpm dub schema:gen`) 会自动生成一个完全结构化的 Move 包和前端集成，包括：

-模块化文件结构
-链上可组合性（通过从 Sui 发布的包中导入）
-本地网络设置、构建、部署和前端支持（Next.js 就绪）

你写逻辑. **dubhe**处理样板文件. 


![](https://ipfs-cdn.peeranha.io/QmfXumBLatEv5Gjc2tZt3WwodoN2bPCLC66Dt3GTohPeCw)

##** ⏱️ 真正的影响：重复代码减少了 80%**

在内部实验中，Dubb生成的项目表明，只有**20％的代码**必须手动编写，其余的是通过架构自动生成的脚手架. 

这意味着更快的原型设计、更少的错误，并有更多时间专注于真正重要的事情：应用程序的核心价值. ![](https://ipfs-cdn.peeranha.io/Qmd2ziWseLyAWkezP8TRRTPkSkpWPNSPBiCuqKfb3LiQSH)


##**开发生态系统引擎**

Dubb 并没有停在脚手架上. Movin明确表示：这是**新开发经济的基础设施**. 

以下是 Dubb Engine 社区的发展历程：

-**汽油补贴：**适用于尝试使用Dubb的新建筑商
-**任务赏金：**像 GitHub 的 “第一期不错的问题”，但有奖励
-**治理层 (D-OS):** 针对项目优先级的链上投票
-**Launchpad 支持：**帮助成熟的项目获得资金
-**dApp Staking：**用户可以质押 D 代币来支持他们最喜欢的 dApp 并对路线图决策进行投票

这种反馈循环推动了整个 Sui 生态系统：更多的开发者 → 更多的应用程序 → 更多的用户 → 更多的开发者. 

![](https://ipfs-cdn.peeranha.io/QmZKE2zQSH8vAyxLBthNffrH6B77Bn9xuMBUdufiYLLAzx)

Let’s be real if you’ve ever built on **Sui**, you’ve probably hit some walls.

From cryptic object IDs to juggling CLIs and spinning up localnets, it’s like prepping for a boss fight before you even write your first line of business logic.

![](https://ipfs-cdn.peeranha.io/Qma8QMuBADaXikAevRLHj9K5EMJ2AZypucXfVVrWxJSntd)

During a recent workshop as part of the Road to Overflow series, Moven from Dubhe Foundation broke down how Dubhe Engine works, what problems it solves, and how it’s more than just a tool — it’s a growing movement.

Video link: https://www.youtube.com/watch?v=CHkOS-TYehM

# The Problem: Fragmented Tooling, Heavy Setup

Moven kicked things off with some real talk about the current Sui dev landscape:

- Newcomers face a steep learning curve: setting up wallets, claiming test tokens, scaffolding packages, learning Move syntax, spinning up local testnets, configuring SDKs, and more.
- Even experienced developers find themselves wasting time on repetitive setup tasks rather than focusing on actual DApp logic.
- Codebases become monolithic fast — large, messy .move files with data structs, constructors, helpers, and entry functions all crammed together.

In short: the ecosystem is growing fast, but the tools haven’t kept up until now.


## **The Solution: Schema-Based Code Generation**

At the heart of **Dubhe Engine** is one key idea: **schema-first development**.

With just one configuration file (d.config.ts), devs can define:

- Their onchain data structures
- Events
- Errors
- Custom types (even 2D vectors of self-defined structs!)

From there, one command (`pnpm dub schema:gen`) auto-generates a fully structured Move package and frontend integration, complete with:

- Modularized file structure
- Onchain composability (via imports from Sui’s published packages)
- Localnet setup, build, deploy, and frontend support (Next.js ready)

You write the logic. **Dubhe** handles the boilerplate.


![](https://ipfs-cdn.peeranha.io/QmfXumBLatEv5Gjc2tZt3WwodoN2bPCLC66Dt3GTohPeCw)

## **⏱️ Real Impact: 80% Less Repetitive Code**

In internal experiments, Dubb-generated projects showed that only **20% of the code** had to be written manually — the rest was scaffolding auto-generated via schemas.

This means faster prototyping, fewer bugs, and more time to focus on what actually matters: your app’s core value.![](https://ipfs-cdn.peeranha.io/Qmd2ziWseLyAWkezP8TRRTPkSkpWPNSPBiCuqKfb3LiQSH)


## **A Dev Ecosystem Engine**

Dubb isn’t stopping at scaffolding. Movin made it clear: this is **infrastructure for a new developer economy**.

Here’s how the Dubb Engine community is evolving:

- **Gas Subsidies:** For new builders experimenting with Dubb
- **Task Bounties:** Like GitHub’s “good first issues,” but with rewards
- **Governance Layer (D-OS):** Onchain voting for project prioritization
- **Launchpad Support:** Helping mature projects secure funding
- **DApp Staking:** Users can stake D-tokens to support their favorite DApps and vote on roadmap decisions

This feedback loop fuels the whole Sui ecosystem: more devs → more apps → more users → more devs.

![](https://ipfs-cdn.peeranha.io/QmZKE2zQSH8vAyxLBthNffrH6B77Bn9xuMBUdufiYLLAzx)

Recap the video can supercharge your Sui Dev Journey

回顾一下这段视频可以为你的 Sui 开发之旅增光添彩

How to access and manage nested structs and dynamic fields in Move?

未回答

分享您的见解和专业知识。

帖子

如果我不通过 Sui bridge 申领 ETH 会怎样？

学习 Solidity After Move 很容易吗？

在 sui 上制作 dapps 服务（如游戏）有利可图吗？

初学者学习动作的最佳去处？

NFT 在 sui 上是如何运作的？

NFT 在 sui 上是如何运作的？

pump.fun on sui？

你好社区

赚取你的 1000 Sui 份额