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 健康度

—

等待部署

托管方0x9e2C…5C6D·Oracle 面板

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

IV.B.1./Wrap 整张 eNAT

整张换 ERC-721。

把整张 eNAT 在协议层 transfer 到多签 EOA，然后调用 wrap(blk, transferTxHash)。oracle 见证 transfer，合约给你铸一张 tokenId = blk 的 ERC-721。

01.发起 emt-transfer从钱包提交规范 emt-transfer：src="«blk»"，amt="1"，to=0x9e2C5e8c…。
02.等待 finalityindexer 需等约 12–15 分钟。在 finality 之前不要调用 wrap()——re-org 可能让两端都破。
03.调用 wrap()调用 IeNATWrapped721.wrap(blk, transferTxHash)。oracle 校验多签签名的 transfer，合约 mint ERC-721 给你。
04.收到 ERC-721钱包持有可转让的 tokenId = blk 的 ERC-721。底层 eNAT 现在位于多签 EOA。

把整张 eNAT 包成 ERC-721。

填一个你目前持有为整张的区块号；amt、to、src 三个字段会自动算出。

区块号你持为整张的 blk，例如 18765432。

自动 · amt: 2,974,172 gwei
自动 · to: 0x9e2C…5C6D
自动 · src: 18765432

实时预览/Calldatavalid

data 字段 · UTF-8

data:,{"p":"edmt","op":"emt-transfer","tick":"enat","amt":"2974172","to":"0x9e2C5e8c1A2B3D4F5C6E7B8A9D0c1E2F3A4B5C6D","src":"18765432"}

Pitfalls

若 to 填成包装合约地址，unwrap 永远走不通。托管方必须是多签 EOA。
在 finality 之前调用 wrap() —— 主网 re-org 可能使 transfer 作废，而合约已经承认了它，会进入无资产可赎回的状态。

IV.B.2./Unwrap 整张 eNAT

ERC-721 换回 raw。

烧掉你的 ERC-721，多签 EOA 代发 emt-transfer 把整张 eNAT 转回你地址。约 12–15 分钟结算。

01.调用 unwrap()调用 IeNATWrapped721.unwrap(blk)。ERC-721 被 burn，合约 emit Unwrapped event。
02.多签代发协议层操作账户监听 Unwrapped，协同签名一笔 emt-transfer：src="«blk»"，to=msg.sender。
03.等待 finalitytransfer 被广播后需 finality；完成后 indexer 才把整张归属改回你。
04.raw 归属复原你重新成为 blk 的协议层持有人，从此与包装层无关。

把 ERC-721 拆回整张。

生成 IeNATWrapped721.unwrap(blk) 的 dry-run calldata。请在持有对应 ERC-721 的钱包里送往 wrapper 合约。

区块号你想拆的 blk（即 ERC-721 tokenId）。

实时预览/Dry-run hexvalid

wrapper.unwrap calldata

0x57a9ec7700000000000000000000000000000000000000000000000000000000011e5678

Pitfalls

若拒签人数 > (N−M)：ERC-721 已 burn，但 emt-transfer 始终没发出。需要走链下升级流程。
不要试图重新 mint 同一区块——first-is-first 已定归属，unwrap 在链上已承认。

IV.B.3./Wrap BURN 碎片

gwei 换 ERC-20。

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

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

把碎片包成 BURN。

填想要 wrap 的 gwei 数与 carrier（区块号 = 拆整张；balance = 从碎片 FIFO 扣）。

数量（gwei）整数 gwei；不支持小数 gwei。来源balance — 从碎片 FIFO 扣；或者填一个区块号去拆整张。

自动 · to: 0x9e2C…5C6D

实时预览/Calldatavalid

data 字段 · UTF-8

data:,{"p":"edmt","op":"emt-transfer","tick":"enat","amt":"23932556","to":"0x9e2C5e8c1A2B3D4F5C6E7B8A9D0c1E2F3A4B5C6D","src":"23287673"}

Pitfalls

wrap 碎片会把你的 FIFO 队列合并入一个共享池，单条碎片的 provenance 在 wrap 后不再可区分。
oracle 健康度低于 M-of-N 时只允许 unwrap 不允许 wrap。提交 step 1 前先看快照面板。

IV.B.4./Unwrap BURN 碎片

ERC-20 换回 gwei。

烧掉你的 BURN ERC-20，多签代发 emt-transfer 把等量 gwei 转回你。约 12–15 分钟结算。

01.调用 withdraw()调用 IBurnWrapped20.withdraw(amtGwei)。合约 burn 你的 BURN 并 emit Withdrawn。
02.多签代发多签发出 emt-transfer：src="balance"，amt="«gwei»"，to=msg.sender。
03.等待 finality约 12–15 分钟。finality 后 indexer 为你记入一条新的 FIFO 碎片。
04.新碎片到账你的地址多出一条 FIFO 末尾的碎片。可以继续 raw 持有、再 wrap、或用作未来 transfer 的 src。

把 BURN 拆回碎片。

生成 IBurnWrapped20.withdraw(amtGwei) 的 dry-run calldata。wrapper 烧掉 BURN 后，多签会反签一笔 emt-transfer 回到你的地址。

数量（gwei）1 BURN = 1 gwei（decimals 9）。

实时预览/Dry-run hexvalid

wrapper.unwrap calldata

0x2e1a7d4d00000000000000000000000000000000000000000000000000000000016d2e8c

Pitfalls

若多签部分掉线：Withdrawn 已 emit，但 emt-transfer 可能延迟到多签达阈值后才发出。
取回的碎片按「当下」入队，不会恢复 wrap 前的原始 provenance。

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 层后丢失：包装层按区块同质，不按「故事」。

阅读合约规范→留在 raw · mint calldata→

当前 包装供给。

gwei 换 ERC-20。

把碎片包成 BURN。

什么时候 值得 wrap。

当前包装供给。

什么时候值得 wrap。