eDMT·eNAT
实时·ETH 主网
区块#24,836,710
·
燃烧0.0134ETH
已出块00s
Plate IV./Plate IV. · 包装

包装成 ERC。

包装会发出可流通的 ERC 债权,其底层 eNAT 在协议层视角下由多签 EOA 持有。相比留在 raw 层,它明确是更高信任暴露的选择。

信任披露 · 应用层

此页面属于 ERC 包装应用层。wrap 资产在协议层视角下由一个多签 EOA 托管。其密钥原则上可以签出任何 emt-transfer。合约层没有任何强制 pause。

托管方(多签 EOA)
0x9e2C5e8c1A2B3D4F5C6E7B8A9D0c1E2F3A4B5C6D
签名阈值
5-of-7
覆盖范围
所有已 wrap 的整张 eNAT 与 BURN 碎片

你随时可以拒绝这一层: 直接用 raw calldata 铸造与转账 ,在协议层直接完成——无合约、无多签、无中间人。

Plate IV.A./包装快照

当前 包装供给。

当前流通中的 wrapped 整张与 BURN 碎片,以及 oracle 多签最新见证的区块。

Wrapped 整张
ERC-721 供给
Wrapped BURN
BURN
ERC-20 供给 · 1 ETH = 10^9 BURN
最新 oracle 见证
#24,836,709block
至少 M 个 indexer 见证的区块
Oracle 健康度
等待部署

本页不签名也不广播交易,只生成 calldata 与 dry-run hex,请你在自己的钱包里送签。

IV.B.3./Wrap BURN 碎片

gwei 换 ERC-20。

把碎片/整张中的一部分 burn 在协议层 transfer 到多签 EOA,然后调用 deposit(amtGwei, transferTxHash);合约给你铸等量的 BURN ERC-20。

  1. 01.发起 emt-transfer构造规范 emt-transfer:src="balance"(或 src="«blk»" 以拆开整张),amt="«gwei»",to=0x9e2C5e8c…。
  2. 02.等待 finality与 wrap 整张一样 12–15 分钟窗口。finality 之前 indexer 不会发出见证。
  3. 03.调用 deposit()调用 IBurnWrapped20.deposit(amtGwei, transferTxHash),oracle 见证该 transfer。
  4. 04.收到 BURN合约 mint amtGwei × 10^9 的 BURN ERC-20 给你(decimals 9)。

把碎片包成 BURN。

填想要 wrap 的 gwei 数与 carrier(区块号 = 拆整张;balance = 从碎片 FIFO 扣)。

自动 · to
0x9e2C…5C6D
实时预览/Calldatavalid
data 字段 · UTF-8
data:,{"p":"edmt","op":"emt-transfer","tick":"enat","amt":"15538571","to":"0x9e2C5e8c1A2B3D4F5C6E7B8A9D0c1E2F3A4B5C6D","src":"21667420"}
Pitfalls
  • wrap 碎片会把你的 FIFO 队列合并入一个共享池,单条碎片的 provenance 在 wrap 后不再可区分。
  • oracle 健康度低于 M-of-N 时只允许 unwrap 不允许 wrap。提交 step 1 前先看快照面板。
Plate IV.C./Plate IV.C. · 为何 wrap

什么时候 值得 wrap。

支持 wrap 的理由
  • 与标准 ERC-721 / ERC-20 生态的可组合性——AMM、市场、投资组合工具一应可用。
  • 碎片获得流动的二级市场,无需承担 P2P gwei 转账中的价格不透明性。
  • 托管抽象——多签可以服务不愿自管私钥生命周期的用户。
反对 wrap 的理由
  • 信任暴露明确更高:多签私钥失守会一次性卷走全部 wrap 供给。
  • 每次 wrap / unwrap 都有约 12–15 分钟的 finality 滞后,不适合短线翻牌。
  • UI 标注(时代、稀有度)在穿过 ERC 层后丢失:包装层按区块同质,不按「故事」。