# [ERC7721] ERC1155形式のNFTを預けずに使い続けるロックの仕組みを理解しよう！

> ERC7721は、ERC1155に「ロック（lock）/アンロック（unlock）」の仕組みを追加する拡張です。対象はERC1155の中でも、とくにNFTとして扱う「特定のtokenId」です。

- URL: https://cardene.dev/articles/c6114950191b9e769388
- 公開日: 2026-01-08
- 更新日: 2026-01-08
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、ERC1155のNFTをウォレットに保持したまま、tokenId単位で移転を制限できるロックの仕組みを提案している**ERC7721**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-7721

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ERC7721**は、**ERC1155**に「**ロック（lock）/アンロック（unlock）**」の仕組みを追加する拡張です。
対象は**ERC1155**の中でも、とくにNFTとして扱う「**特定の`tokenId`**」です。

:::message
**ERC1155**については以下の記事を参考にしてください。
:::

[\[ERC1155\] ERC1155を1からわかりやすく解説](/articles/c3ef92722b057161bebd)

ロックされている間、その `tokenId` は売買や譲渡（`transfer`）ができなくなります。
一方で、NFTが持つそれ以外の性質（ゲーム内での利用、会員証としての利用など）は、所有者のウォレット内にあるまま維持できます。

この仕組みの中心は、以下の3つの権限と状態です。

* 所有者（`owner`）がNFTをロックできること
* ロック解除の権限を持つ「**解除担当（locker）**」というアドレスを設定できること
* ロックに関する権限や承認（`approval`）がトークン移転時にリセット（`purge`）されること

ここで出てくる用語は以下です。

| 用語 | 説明      |
| ------------ | ----------- |
| EOA   | 個人が秘密鍵で操作する通常のウォレットアドレス（例: MetaMaskのアカウント）です。                |
| コントラクトアドレス   | スマートコントラクトとして動作するアドレスです。プログラムに従って自動実行できます。                   |
| `locker`（解除担当） | ロックされたNFTをアンロックできる唯一のアドレスです。EOAでもコントラクトでも構いません。              |
| `approval`（承認） | 所有者が、特定のアドレスに対してトークン操作を許可する仕組みです（**ERC1155**の承認概念を前提にしています）。 |
| `tokenId`  | **ERC1155**で「**どの種類のトークンか**」を表すIDです。同じコントラクト内で複数種のトークンを区別します。    |
| `purge`（権利の消去） | トークンが移転されたときに、ロック/承認などの付随権限が消えることです。前の所有者の設定が残らないようにします。     |

**ERC7721**の特徴は、「**所有者のセルフカストディ（self-custody）**」を崩さずに、NFTの移転だけを止められる点です。
セルフカストディとは、NFTをエスクロー（第三者管理の預かり）コントラクトに送らず、所有者自身のウォレットに保持し続けることです。

さらに、ロック解除の権限を持つ `locker` を設定できるため、例えば「**普段使うホットウォレットにNFTを置いたまま、解除権限はコールドウォレットに持たせる**」といった運用が可能になります。
これにより、盗難リスクを下げながらユーティリティ利用を継続できます。

#### ロックと解除の権限モデル

**ERC7721**では、ロックと解除に関して以下のような権限分離が想定されています。

所有者は、NFTをロックするときにlockerを指定します。
ロックされたNFTは、lockerだけがアンロックできます。
つまり、所有者がロックしても、解除権限は所有者ではなく `locker` に渡す設計にできます（もちろん、所有者自身をlockerにすることも可能です）。

また、所有者は `tokenId` に対する承認を与えることができます。
承認を持つアドレスは、その承認を使って「**資産をロックする**」運用が可能になります。
さらに、承認を持つ側が自分自身を `locker` として設定してロックすることもできます。
これにより、レンタルや貸付のように「**所有者以外がロックを開始する**」形も作れます。

ただし、NFTが移転された瞬間に、ロックや承認に関する権利は消去されます。
これは、前の所有者や第三者が設定した `locker` や承認が、新しい所有者に引き継がれてしまう事故を防ぐための重要な仕様です。

#### 「ロックされたトークンからの引き出し」という考え方

概要には「**ロックされたトークンから、承認されたユーザーがあらかじめ決めた量だけ引き出せる**」という表現があります。
ここで言う「**引き出し**」は、現実の金庫のように中に入れているトークンを部分的に取り出すというより、ロック状態のトークンについて、特定の `tokenId` と数量（`amount`）を条件に操作できるようにする、という意図です。

**ERC1155**は「**同じ `tokenId` を複数枚（`amount`）持てる**」標準なので、NFT用途でも「**1枚=`amount` 1**」として扱うのが一般的ですが、標準としては数量の概念があるため、`tokenId` 単位・数量単位で制御できる設計が意識されています。

## 動機

**ERC1155**の普及によりNFT需要は大きく伸びましたが、NFT経済には「**二次流動性（secondary liquidity）の弱さ**」があります。
ここでいう二次流動性は、単に売れる/売れないではなく、「**所有者のウォレット内にあるNFTが、金融的に活用しづらく眠ってしまう**」状態を指しています。

NFTの流動性を高めるプロジェクトはすでに存在しますが、多くは「**NFTをそのプロジェクトのコントラクトへ移転して預け入れる**」ことを前提にします。
これが以下の不便やリスクにつながります。

#### 課題1: ユーティリティの喪失

NFTをエスクローに移してしまうと、所有者のウォレットにNFTが存在しなくなります。
その結果、NFTが鍵となっているユーティリティが使えなくなることがあります。

例えば、Discordの認証や、ゲーム内でのアイテム利用などが「**ウォレットがNFTを保持していること**」を条件にしている場合、エスクローに移した瞬間に利用権が失われます。
つまり、NFTを金融的に活用するために預ける行為が、NFTとしての価値（機能）を落とす行為になり得ます。

#### 課題2: コンポーザビリティの不足

コンポーザビリティは、「**部品のように組み合わせて使える性質**」です。
DeFiでは、資産を担保に借りて、その借りた資産を別のプロトコルで運用するといった組み合わせが一般的です。

しかしNFTはエスクロー型の仕組みに預けると、別の用途に同時活用しにくくなります。
本来であれば、NFT所有者がローン、レンタル、その他の金融ツールを同時に使い分けられると市場効率は上がりますが、預け入れが前提だとそれが難しくなります。

#### 課題3: スマートコントラクト脆弱性のリスク

NFTを預け入れるコントラクトにバグや脆弱性があると、NFTが失われたり盗まれたりする可能性があります。
NFTを外部コントラクトへ移転すること自体が、攻撃面（attack surface）を広げます。

この3つの課題はUX（ユーザー体験）を悪くします。
そこで**ERC7721**は、NFTをコントラクトへ移転せず、所有者のウォレットに置いたままロックする「**ネイティブなロック機構**」を入れることで解決を狙います。

#### ロック中もユーティリティを維持するという考え方

**ERC7721**では、ロック期間中は譲渡だけが制限されます。
NFT自体は所有者のウォレットに残り、ユーティリティは基本的に変わりません。
つまり「**担保にしている間も、会員証として使う**」、「**ゲーム内で装備として使う**」といったことが成り立ちます。

これは不動産の例と同じ発想です。家を担保にローンを組んでも、その家に住み続けられます。
NFTも同様に、担保としての役割を持ちながら、所有者が価値を使い続けられる状態が望ましい、という動機です。

#### 想定ユースケース

以下は、**ERC7721**が挙げているユースケースです。

| ユースケース | 説明    |
| ----------------------- | ------- |
| NFT担保ローン  | NFTをレンディングプロトコルに送らず、所有者のウォレットでロックして担保として使います。担保性（勝手に売れない）とユーティリティ継続を両立します。  |
| 無担保に近いNFTレンタル           | 借り手は手数料を払いNFTを使えますが、譲渡はできません。貸し手の安全性が上がります。レンタル期間終了後、サービスコントラクトが貸し手へ自動返却する想定です。                   |
| BNPL（Buy Now Pay Later） | 購入者はロックされたNFTを受け取り、すぐ使えますが、完済まで売却できません。支払い不能ならNFTは売り手に戻り、手数料も得られる想定です。  |
| コンポーザビリティ | NFTを担保に借りつつ、同じNFTをレンタルに回して収益を得るなど、複数の金融ツールを組み合わせやすくします。  |
| 一次販売（Primary sales）  | NFTを一部支払いでミントし、残額を後で精算する形を取りやすくします。    |
| Soulbound  | 譲渡不可に近いNFTの運用です。組織がミントし、自分自身をlockerに指定してユーザーへ送付し、資産をロックします。     |
| 安全性の向上   | 所有者はホットウォレット（例: MetaMask）にNFTを置いて使い、解除権限はコールドウォレットに持たせられます。ホットウォレットが侵害されても、コールドウォレットがなければ譲渡できません。 |

「**Soulbound**」は、一般に譲渡できない（または極めて制限された）NFTを指す言い方です。
ここでは、`locker` を組織側に固定することで、ユーザー側が勝手に移転できない状態を作る意図です。

#### 他のロック提案との違い

**ERC7721**は、同じ「**NFTロック**」を扱う他の提案と比べて、以下の点が異なるとしています。

##### 最小限のlock/unlockに絞る方針

**ERC7721**は、時間制限付き（time-bound）のロック解除のような具体条件を標準仕様に含めません。
ロック解除の条件は、返済完了、期限到来、その他の合意条件など、プロトコル側のスマートコントラクトで実現できるためです。

つまり**ERC7721**は「**ロック/解除という原語的な機能だけを提供し、解除条件の多様性は上位レイヤーに任せる**」という設計思想です。

##### `locker` と `approver` の権限分離

**ERC7721**では、ロック解除の権限（`locker`）と、承認による操作権限（`approver`）を分けて考えます。

* 承認を使ってロックし、承認者が解除や引き出しをできる形は、レンタル・レンディング・BNPLのような「**第三者が運用する**」仕組みに向きます。
* 一方で、ロックはできても「**権利を取り消せない（revocationできない）状態**」を作りつつ、必要なら解除できる、という形は「**アカウントに紐づくNFT（account-boundに近い運用）**」に向きます。

ここでの「**revocation**」は「**取り消し**」です。
例えば、誰かに与えた権限を後から無効化することを指します。

##### `transferAndLock の導入

**ERC7721**はtransferAndLockという機能を持てる設計を提案しています。
これは、送付（`transfer`）とロック（`lock`）を一連の操作として実行し、必要なら承認（`approve`）もまとめて設定できる、という考え方です。

これにより、NFTを受け取った直後からロック状態にして、さらに「**あとから取り消し（revocation）できる余地**」を持たせるなど、移転後の運用設計がしやすくなります。

## 仕様

#### 概要

**ERC7721**は、**ERC1155**に準拠したトークンコントラクトに対して、「**トークンを現在の所有者のウォレット内でロック・アンロックする標準的な方法**」を提供します。

ここで重要なのは、「**ロックされてもトークンは所有者のウォレットから移動しない**」という点です。
**ERC7721**を実装したコントラクトは、ロックされたトークンについて、移転可能な数量を制限します。

ロックは `tokenId` 単位かつ `amount`（数量）単位で行われます。
**ERC1155**は同じ `tokenId` を複数枚持てるため、「**どれだけロックされているか**」を数量で管理します。

#### ロックとアンロックの基本動作

##### ロックの方法

トークンのロックは以下の2通りがあります。

1つ目は、所有者が `locker` を指定してロックする方法です。
`lock(tokenId, account, _locker, amount)` を使い、解除権限を持つアドレス（`locker`）を明示的に設定します。

2つ目は、所有者または承認済みアドレスが自分自身を `locker` としてロックする方法です。
`lock(tokenId, account, amount)` を使うと、`locker` は `msg.sender` に設定されます。

どちらの場合も、ロック対象のアカウントが十分な残高を持っていなければなりません。
また、呼び出し元が所有者または承認済みでなければ、処理は `revert` します。

##### アンロックの方法

アンロックは、`locker` に設定されたアドレスのみが実行できます。
`unlock(tokenId, account, amount)` により、指定した数量分のロックを解除します。

ロックされていない数量を解除しようとした場合は `revert` します。

#### 承認（`Approval`）の拡張

**ERC7721**では、**ERC1155**の通常の承認とは別に、「tokenId 単位の承認」が導入されています。

`setApprovalForId(tokenId, operator, amount)` により、特定の `tokenId` について、`operator` が使える数量を設定します。

`getApprovalForId(tokenId, account, operator)` は、その承認数量を返します。

これにより、「**この `tokenId` だけ**」、「**この数量まで**」という細かい制御が可能になります。
レンタルや分割利用などのユースケースを想定した設計です。

#### ロック状態の取得

`getLocked(tokenId, account, operator)` は、指定された `operator` が `account` 上でロックしている数量を返します。

* ロックされていない場合は **0** を返します。
* ロックされている場合は、ロック中の数量を返します。

この戻り値を使って、「**今どれだけ移転できるか**」を判断します。

#### トークン移転時の制約

**ERC7721**を実装したコントラクトでは、**ERC1155**の `safeTransferFrom` に制約がかかります。

ロックされている数量は移転できません。
移転可能な最大数量は次の式になります。

```
移転可能数量 = 残高 - getLocked(...)
```

ロック数量を超えて移転しようとすると、トランザクションは `revert` します。

#### `transferAndLock` の考え方

**ERC7721**は `transferAndLock` 関数を提供します。

これは「**トークンの移転**」と「**ロック**」を1つの操作として実行する関数です。
さらに、必要に応じて `locker` に対する承認も同時に設定できます。

この関数は、以下のようなケースで推奨されています。

* 移転直後に必ずロックしたい場合
* 移転後にロック解除や権限取り消し（`revocation`）が必要な場合

### インターフェース

```js:IERCLockable1155.sol
// SPDX-License-Identifier: CC0-1.0

pragma solidity >=0.7.0 <0.9.0;

/// @title Lockable Extension for ERC1155
/// @dev Interface for the Lockable extension
/// @author piyush-chittara 

interface IERCLockable1155 is IERC1155{

    /**
     * @dev Emitted when tokenId is locked
     */
    event Lock(uint256 indexed tokenId, address account, address _locker, uint256 amount);

    /**
     * @dev Emitted when tokenId is unlocked
     */
    event Unlock (uint256 indexed tokenId, address account, address _locker, uint256 amount);

    /**
     * @dev Lock the tokenId if msg.sender is owner or approved and set locker to msg.sender
     */
    function lock(uint256 tokenId, address account, uint256 amount) external;

    /**
     * @dev Lock the tokenId if msg.sender is owner and set locker to _locker
     */
    function lock(uint256 tokenId, address account, address _locker, uint256 amount) external;

    /**
     * @dev Unlocks the tokenId if msg.sender is locker
     */
    function unlock(uint256 tokenId, address account, uint256 amount) external;

    /**
     * @dev Tranfer and lock the token if the msg.sender is owner or approved. 
     *      Lock the token and set locker to caller
     *      Optionally approve caller if bool setApprove flag is true
     */
    function transferAndLock(address from, address to, uint256 tokenId, uint256 amount, bool setApprove) external;

    /**
     * @dev Returns the wallet, that is stated as unlocking wallet for the tokenId.
     *      If (0) returned, that means token is not locked. Any other result means token is locked.
     */
    function getLocked(uint256 tokenId, address account, address operator) external view returns (uint256);

    function setApprovalForId(uint256 tokenId, address operator, uint256 amount) external;
}
```

#### イベント

##### `Lock`

```javascript
event Lock(uint256 indexed tokenId, address account, address _locker, uint256 amount);
```

`tokenId` がロックされた時に発行されるイベント。
トークンがロックされたことを外部に通知するためのイベントです。
どの `tokenId` が、どのアカウント上で、誰を `locker` として、どの数量ロックされたかが分かります。

**パラメータ**

* `tokenId`
  * ロック対象のトークンID。
* `account`
  * トークンを保有しているアカウント。
* `_locker`
  * アンロック権限を持つアドレス。
* `amount`
  * ロックされた数量。

##### `Unlock`

```javascript
event Unlock(uint256 indexed tokenId, address account, address _locker, uint256 amount);
```

`tokenId` のロックが解除された時に発行されるイベント。
ロック解除が行われたことを示すイベントです。
どの `locker` によって、どの `tokenId` がどの数量解除されたかを確認できます。

**パラメータ**

* `tokenId`
  * 対象のトークンID。
* `account`
  * トークンを保有しているアカウント。
* `_locker`
  * ロック解除を実行したアドレス。
* `amount`
  * 解除された数量。

#### 関数

##### `lock`

```javascript
function lock(uint256 tokenId, address account, uint256 amount) external;
```

トークンをロックし、呼び出し元を `locker` に設定する関数。
所有者または承認済みアドレスが実行できます。
`locker` は `msg.sender` に設定されます。
指定した数量分のトークンが移転不可になります。

**引数**

* `tokenId`
  * ロック対象のトークンID。
* `account`
  * トークンを保有しているアカウント。
* `amount`
  * ロックする数量。

##### `lock`

```javascript
function lock(uint256 tokenId, address account, address _locker, uint256 amount) external;
```

トークンをロックし、任意の `locker` を設定する関数。
所有者のみが実行できます。
解除権限を第三者に委譲したい場合に使用します。

**引数**

* `tokenId`
  * ロック対象のトークンID。
* `account`
  * トークンを保有しているアカウント。
* `_locker`
  * アンロック権限を持つアドレス。
* `amount`
  * ロックする数量。

##### `unlock`

```javascript
function unlock(uint256 tokenId, address account, uint256 amount) external;
```

ロックされたトークンを解除する関数。
`locker` に設定されたアドレスのみが実行できます。
ロックされていない数量を解除しようとすると `revert` します。

**引数**

* `tokenId`
  * 対象のトークンID。
* `account`
  * トークンを保有しているアカウント。
* `amount`
  * 解除する数量。

##### `transferAndLock`

```javascript
function transferAndLock(
    address from,
    address to,
    uint256 tokenId,
    uint256 amount,
    bool setApprove
) external;
```

トークンを移転し、そのままロックする関数。
移転とロックを1トランザクションで行います。
`setApprove` が `true` の場合、`locker` に対して承認も設定されます。
移転後の `revocation` を想定したユースケースで推奨されます。

**引数**

* `from`
  * 送信元アドレス。
* `to`
  * 受信先アドレス。
* `tokenId`
  * 対象のトークンID。
* `amount`
  * 移転・ロックする数量。
* `setApprove`
  * 承認を同時に設定するかどうか。

##### `getLocked`

```javascript
function getLocked(
    uint256 tokenId,
    address account,
    address operator
) external view returns (uint256);
```

指定された条件でロックされている数量を返す関数。
`operator` が `account` 上でロックしている数量を返します。
ロックされていない場合は `0` を返します。

**引数**

* `tokenId`
  * 対象のトークンID。
* `account`
  * トークン保有アドレス。
* `operator`
  * `locker` または確認対象のアドレス。

**戻り値**

* `uint256`
  * ロックされている数量。

##### `setApprovalForId`

```javascript
function setApprovalForId(
    uint256 tokenId,
    address operator,
    uint256 amount
) external;
```

`tokenId` 単位で承認数量を設定する関数。
特定の `tokenId` について、`operator` が使える数量を指定します。
**ERC1155**の全体承認よりも細かい制御が可能です。

**引数**

* `tokenId`
  * 対象のトークンID。
* `operator`
  * 承認を与えるアドレス。
* `amount`
  * 承認する数量。

## 補足

**ERC7721**は `transferAndLock(address from, address to, uint256 tokenId, uint256 amount, bool setApprove)` を公開します。
これは「**トークンを移転する**」と「**受け取り側でロックする**」を一度に行うための関数です。
受け取った側はトークンを持てますが、ロックされているので勝手に譲渡できません。
つまり、受け取り側に条件付きの所有を与えるための仕組みです。

`setApprove` は追加のスイッチで、`true` にすると「**`locker` に承認（`approval`）を付与する**」動きになります。
これにより `locker` は、単にロック解除できるだけでなく、承認を根拠にトークンを動かせる立場になれます。
ここで重要なのは、実際の取り消し（`revocation`）の条件は**ERC7721**が決めるのではなく、周辺コントラクト側で定義できる点です。
例えば、「**分割払いが滞ったら回収**」、「**レンタル期限を過ぎたら返却**」、「**返済が完了したら解放**」といった条件をサービスコントラクトが判断し、承認を持つ locker（多くはそのサービスコントラクト）が回収や返却処理を実行できます。

まとめると、`transferAndLock` は次の状態を作るために用意されています。

| 作りたい状態 | `transferAndLock` が担う部分         |
| ----------------------------- | ------------- |
| 受け取り側に `tokenId` を渡し、すぐ使えるようにする | `transfer`（移転）  |
| ただし売買や第三者への譲渡はさせない | `lock`（ロック）   |
| 条件次第で回収や解除などの運用を可能にする         | `setApprove=true` による承認付与（条件は周辺コントラクトで定義） |

この結果、受け取り側は「**使えるが、自由に転売できない**」状態になります。BNPLやレンタルで欲しい挙動に寄せやすい設計です。

## 互換性

**ERC7721**は**ERC1155**と互換です。
ここでいう互換は、**ERC1155**が定める基本的なインターフェースや挙動を崩さずに、ロック機能を追加できるという意味です。

そのため、既存のUpgradeable（アップグレード可能）な**ERC1155**コントラクトは、実装を更新することで**ERC7721**のロック機能を取り込めます。
こうすると、今まで「**NFTを外部コントラクトに預けないとできなかった流動性の仕組み（貸付、レンタル、分割払いなど）**」を、トークン側の機能として持てるようになります。

## 参考実装

https://eips.ethereum.org/assets/eip-7721/IERC7721.sol

https://eips.ethereum.org/assets/eip-7721/ERC7721.sol

## セキュリティ

#### ロックされた数量は移転できない

一度ロックされた `amount` は、ロックされたアカウントから移転できません。
これは**ERC7721**の中核で、`safeTransferFrom` などでロック分を超えて動かそうとすると `revert` する前提です。
レンタルや担保で「**勝手に逃げられない**」性質を作れます。

##### `locker` かつ承認済みの場合、移転できる

「**トークンがロックされていて、呼び出し元が `locker` であり、かつ承認も持っている場合、その呼び出し元はトークンを移転できる**」とあります。

これは、ロック解除の権限だけでなく、承認（`approval`）もセットで持たせると、`locker` 側がトークン移転を実行できる、という意味です。
`transferAndLock` の `setApprove=true` がまさにこの前提を作ります。
結果として、回収・返却など `revocation` 的な動きを `locker`（サービスコントラクト）が行えるようになります。

ここは便利な一方、設計を誤ると「**想定より強い権限**」を `locker` に与えることにもなります。
運用側は、どのケースで承認を付けるのかを明確に決める必要があります。

#### アクセス不能な `locker` を指定すると永久ロックになり得る

「**in-accesible account**」は「**アクセスできないアカウント**」という意味です。
例えば、秘密鍵を紛失したEOAや想定通りに動かないコントラクトアドレスを `locker` に指定すると、ロック解除ができず、結果として永久にロックされたままになる可能性があります。

また「**un-verified contract address**」は「**検証されていない（中身が不明な）コントラクトアドレス**」というニュアンスです。
実装が公開されていない、あるいは期待する `unlock` を提供していないコントラクトを `locker` にすると、解除不能になるリスクがあります。

この点は、ロックが安全装置である一方、取り返しのつかない設定にもなり得ることを示しています。
とくに `lock(tokenId, account, _locker, amount)` のように所有者が `locker` を自由指定できる場合、設定ミスがそのまま資産ロックにつながります。

#### MEV（最大抽出可能価値）に関する考慮はない

MEVは、トランザクションの順序操作などで利益を抜く行為・構造のことです。
「**ロック・アンロックができるのは権限を持つ当事者だけなので、ロック可能トークン自体にMEVの考慮はない**」としています。

つまり、誰でもロックできたり解除できたりする公開操作ではないため、第三者が順序を操作して得をする余地が基本的に生まれない、という整理です。

## 引用

Piyush Chittara (@piyush-chittara), "ERC-7721: Lockable Extension for ERC-1155 [DRAFT]," Ethereum Improvement Proposals, no. 7721, May 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7721.

## 最後に

今回は「ERC1155のNFTをウォレットに保持したまま、tokenId単位で移転を制限できるロックの仕組みを提案している**ERC7721**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4