> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ja/canton-zk-evm/deposits-withdrawals-payments.md).

# 入金、出金、および支払い

ゲートウェイがEVMの入金、出金、支払いをそれぞれのCanton側の処理にどう結び付けるか。

ゲートウェイはチェーンのジェネシスに含まれる EVM コントラクトです。これは、ブロックが Canton に何をさせる必要があるかを記録します。各リクエストはレグです。ブロックの証明は、記録された順序でのレグのハッシュを含め、ゲートウェイの状態にコミットします。

このページではコミットを説明します `a84e84e439a5cc669c0ae61facf7c8c995d9d564`。完全版を読む [gateway README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/gateway/README.md) と [Daml インターフェース](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md).

| レグ   | ゲートウェイ呼び出し                       | EVM アクション                | Canton のアクション `進行`                        |
| ---- | -------------------------------- | ------------------------ | ----------------------------------------- |
| 預け入れ | `claim(id, token, amount)`       | 呼び出し元にラップ済みトークンをミントします。  | 預け入れ者の割り当てをゲートウェイに対して実行します。               |
| 引き出し | `withdraw(token, amount, party)` | 呼び出し元のラップ済みトークンをバーンします。  | ゲートウェイの保管下にある Canton トークンを指定された当事者に支払います。 |
| 支払い  | `pay(id, token, to, amount)`     | 支払者から受取人へ ERC-20 を移転します。 | 合意した支払条件で指定された割り当てを実行します。                 |

## Canton トークンを預け入れる

預け入れ者は、実行者をオペレーターとして、Canton トークンをゲートウェイに割り当てます。預け入れ者は 1 つの `預け入れ要求` 預け入れ ID、claim を許可された EVM アドレス、および割り当てを指定します。

その EVM アドレスが呼び出します `claim`。ゲートウェイは呼び出し元にミントし、預け入れレグを記録します。受取人はガスに tROME が必要です。ビルダーはレグをリクエスト、登録済みトークン、および割り当てに一致させます。

`進行` ゲートウェイの保管下で割り当てを実行し、ラップ済みトークンをミントしたブロックをコミットします。ラップ済みトークンは 10 桁の小数を持ち、Canton の金額に一致します。2 つの金額の変換は正確で、丸めはありません。

## Canton の当事者へ引き出す

保有者が呼び出します `withdraw` ラップ済みトークン、金額、および完全な Canton 当事者 ID を指定して。ゲートウェイはラップ済みトークンをバーンし、受取人をレグに記録します。

受取人は 1 つの `引き出し承諾`。アーカイブされるまで有効です。ビルダーには、登録済みのインストゥルメントのロック解除済みゲートウェイ保有残高も十分に必要です。これらの条件を満たさない場合、トランザクションは除外されます。

`進行` トークンレジストリの transfer factory を通じて受取人に支払います。Canton の移転と、バーンを含むブロックは一緒にコミットされます。ビルダーは、builder README で説明されているように、1 ブロックにつき 1 つのインストゥルメントの引き出しを高々 1 件しか含めません。 [builder README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md).

## 支払いを 1 つの割り当てに結び付ける

U は Canton トークンを V に割り当てます。U と V は `DvpTerms` 割り当て、支払い ID、EVM トークン、EVM 受取人、および金額を指定します。支払い ID は UTF-8 テキスト `<U の当事者 ID>,<V の当事者 ID>,<ラベル>`を小文字の 16 進数で記述します。条件はそれ以外の ID を拒否します。

V はゲートウェイを承認し、呼び出します `pay` その ID で。ゲートウェイは ERC-20 を V から受取人へ移し、支払いレグを記録します。 `進行` 署名済みの条件を使用して、U から V への割り当てを実行します。

通常の ERC-20 移転ではレグは記録されません。同じブロック内で同じトークンを同じ受取人へ移転しても、〜の代わりにはなりません。 `pay`。 [設計の支払いフロー](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md#the-flows) この結び付きを説明します。

## 証明が固定するもの

各レグは、種別、ID、トークン、アカウント、金額、および該当する場合は Canton 当事者を記録します。ゲートウェイはレグを順番にハッシュします。 `進行` 取り付けられたレグが、証明されたゲートウェイ状態におけるハッシュを生成することを検証します。レグが欠けている、余分である、順序が入れ替わっている、または変更されていると、トランザクションは失敗します。この検証は、レグのないブロックも対象です。

ブロックを証明しても、その Canton の割り当ては予約されません。送信者は、決済前であればまだ割り当てを取り戻せます。証明後にそれが起きると、Canton は拒否します `進行` そして reth は最後にコミットされたブロックに戻ります。レグを削除した同じ証明済みブロックを再送信することはできません。次のビルドでは支払いが省かれます。これは次で示されています。 [実行 4](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#results).

## トークンと保管の制限

Canton トークンは、オペレーターの参加者上のゲートウェイ当事者によって保有されます。その参加者を実行する者は誰でもそれらを動かせます。トークンを登録することは、そのレジストリの Daml コードを信頼することも意味します。そのコードはゲートウェイの権限で実行されます。

ゲートウェイの EVM アドレスに直接送られたトークンは回収できません。トークンが送金手数料を課すか、あるいは別の金額を移転する場合でも、支払いレグには実際に移転された金額ではなく、要求された金額が記録されます。次を読む [信頼モデルと制限](/ja/canton-zk-evm/trust-model.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/ja/canton-zk-evm/deposits-withdrawals-payments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.