Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

トランザクションポリシールールを作成する

このページでは、トランザクションポリシーで確認できる属性について説明し、Ethereum（ETHEREUM_TX_V2 と EIP712_TYPED_DATA_V1）、Bitcoin（BITCOIN_TX_V2）、Solana（SOLANA_TX_V1）のトランザクションのルール例を示します。

ポリシーの組み合わせ方法、適用されるポリシー、トランザクションが拒否される理由については、トランザクションポリシーの評価をご覧ください。

ルールの構造

トランザクションポリシーは、プリンシパル、アクション、リソース、コンテキストに対する単一の Cedar permit または forbid ステートメントです。

permit (
  principal,
  action == Action::"buy_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.principal_keyring == "institutional-treasury" &&
  context.schema == "ETHEREUM_TX_V2" &&
  context has amount_token_scaled && context.amount_token_scaled <= 1000000000
};

次の点にご注意ください。

属性はコンテキストの最上位にあります。v1alpha1 のように、context.transaction.spend_amount_scaled ではなく context.amount_token_scaled と記述します。
一部の属性は省略可能です。コンテキストにないオプションの属性があると、ポリシーの評価が失敗し、評価に失敗したポリシーは一致しません。オプションの属性を読み取る前に has で確認するか、forbid ルールで unless { context has ... } を使用して確認します。詳細については、シナリオ 6 とシナリオ 8 をご覧ください。
Cedar 文字列では大文字と小文字が区別されます。各チェーンのテーブルに記載されている形式でアドレスを比較します。

プリンシパルについては、Cedar リクエストをご覧ください。CreateTransaction が受け入れるアクション（buy_transaction、sell_transaction、internal_transfer_transaction）については、アクションとリソースをご覧ください。

コンテキスト属性

各トランザクションのコンテキストには、ペイロードからデコードされた属性、署名鍵とその KeyRing の ID、イニシエーターが設定するメタデータ属性（fiat_amount、validity、principal_value1、principal_value2）が含まれます。

ペイロード属性は、すべてのブロックチェーンで同じです。次の表に、すべてのコンテキスト属性を示します。Ethereum、Bitcoin、Solana の表に、マルチパーティコンピューティングがそのブロックチェーンの各属性にどのように入力するかを示します。

属性	Cedar タイプ	常に表示	値
`schema`	`String`	はい	ペイロード形式: `"ETHEREUM_TX_V2"`、`"BITCOIN_TX_V2"`、`"SOLANA_TX_V1"`、`"EIP712_TYPED_DATA_V1"`。詳細については、スキーマ名をご覧ください。
`blockchain`	`String`	はい	`"ETH"`、`"BTC"`、または `"SOL"`。
`principal_keyring`	`String`	はい	署名鍵を保持する KeyRing の ID（例: `"treasury"`）。
`principal_key`	`String`	はい	署名鍵の ID（例: `"hot-wallet-1"`）。
`secondary_key`	`String`	はい	宛先アドレス、トークンまたは NFT の受取人、承認された支出者またはオペレーター、ペイロードからデコードされた EIP-712 の相手方。
`amount_token_scaled`	`Long`	いいえ	転送または承認された代替可能な金額。アセットの 10^-9 単位。代替可能な金額が転送されない場合（ERC-721 オペレーションや ETH を送信しないコントラクト呼び出しなど）は省略されます。詳細については、金額をご覧ください。
`token_symbol`	`String`	いいえ	アセットのシンボル（`"ETH"`、`"BTC"`、`"SOL"`、`"USDC"` など）。アセットがマルチパーティコンピューティングで認識されない場合、および ERC-721 オペレーションの場合は省略されます。
`contract_address`	`String`	いいえ	ERC-20 または ERC-721 トークンコントラクト、または呼び出されたコントラクト（Ethereum）、検証コントラクト（EIP-712）、またはミント（Solana）。ネイティブ転送では省略されます。
`token_standard`	`String`	いいえ	`"ERC721"`: ERC-721 の転送と承認（`ETHEREUM_TX_V2`）。ネイティブ転送と代替可能トークンのオペレーションでは省略されます。
`token_id`	`String`	いいえ	256 ビットの ERC-721 `tokenId`（10 進数の文字列（`ETHEREUM_TX_V2`））。`setApprovalForAll` と ERC-721 以外のトランザクションでは省略されます。
`from_address`	`String`	いいえ	ERC-721 `transferFrom` および `safeTransferFrom` 呼び出しの現在の所有者（`from`）。大文字と小文字が混在する EIP-55 チェックサム形式。
`approve_all`	`Bool`	いいえ	ERC-721 `setApprovalForAll(operator, approved)` の `approved` フラグは、オペレーターの承認を付与する場合は `true`、取り消す場合は `false` を呼び出します。
`deadline`	`Long`	いいえ	`EIP712_TYPED_DATA_V1` メッセージの有効期限（Unix エポックからの経過秒数）。`deadline`、`sigDeadline`、`validBefore` フィールドから取得されます。
`eip712`	`Record`	いいえ	構造化された EIP-712 ペイロード: `primary_type`、`domain`、`message`。256 ビット整数を 10 進数文字列として使用します。`EIP712_TYPED_DATA_V1` のみ。
`chain_id`	`Long`	いいえ	EVM チェーン ID。たとえば、Ethereum メインネットの場合は `1`、Sepolia の場合は `11155111` です。Ethereum と EIP-712 のみ。
`max_fee_atomic`	`Long`	はい	トランザクションで支払うことができるネットワーク手数料の最大額。ブロックチェーンのネイティブコインの 10^-9 単位で指定します。`0`: `EIP712_TYPED_DATA_V1`。
`payload`	`String`	はい	ペイロードの 16 進数エンコードされたダイジェスト（小文字）。
`time_stamp`	`Long`	はい	トランザクションの `createTime`（Unix エポックからの秒数）。
`key_lists`	`Record`/`Set<String>`	はい	インスタンス内の各 KeyList ID を、その KeyList 内のブロックチェーンアドレスの `Set<String>` にマッピングするレコード。`createTime` で解決されます。インスタンスに KeyList がない場合は空のレコード。`context.key_lists["trusted-destinations"]` などのブラケット構文を使用して KeyList を読み取ります。詳細については、Cedar コンテキストの KeyList をご覧ください。

principal_keyring と principal_key は ID であり、完全なリソース名ではありません。鍵 ID は、KeyRing 内でのみ一意です。principal_keyring を確認して、KeyRing のすべての鍵にルールを適用するか、両方の属性で 1 つの鍵を指定します。

context.principal_keyring == "treasury" && context.principal_key == "hot-wallet-1"

ペイロードを Transaction.schema のパーサーでデコードできない場合、またはコンテキストに投影できない場合、ポリシーは評価されず、トランザクションは UNRECOGNIZED_PAYLOAD で拒否されます。詳細については、拒否の理由をご覧ください。

スキーマ名

schema 属性は、v1beta API の PayloadSchema 値の名前（"ETHEREUM_TX_V2"、"BITCOIN_TX_V2"、"SOLANA_TX_V1"、"EIP712_TYPED_DATA_V1"）です。v1alpha1 ルールで使用される小文字の名前（"ethereum.transaction.v2" など）は、v1beta で一致しません。

schema または blockchain チェックのないルールは、すべてのブロックチェーンに適用されます。ルールを 1 つのブロックチェーンに制限するには、schema を確認します。

金額

amount_token_scaled と max_fee_atomic は、すべてのアセットに同じスケールを使用します。1 単位はアセットの 10^-9 であるため、任意のアセットの 1.0 は 1000000000 です。ルールの値を取得するには、金額に 1,000,000,000（10⁹）を掛けます。次の表に例をいくつか示します。

金額	`amount_token_scaled`
0.1 ETH	`100000000`
1.0 ETH、1.0 BTC、1.0 SOL、1.0 USDC	`1000000000`
0.0025 BTC（250,000 サトシ）	`2500000`
1.5 SOL（1,500,000,000 ランポート）	`1500000000`
5,000 USDC	`5000000000000`

ETH など、小数点以下が 9 桁を超えるアセットの場合、10^-9 未満の金額部分は削除されます。ルールでは確認できません。

Ethereum

次の表に、ETHEREUM_TX_V2 ペイロード（RLP エンコードされたレガシートランザクションと EIP-2718 トランザクション（EIP-1559 を含む））のコンテキスト属性を示します。

属性	値
`secondary_key`	ETH の送金とコントラクトの呼び出しの場合、トランザクションの `to` アドレス。ERC-20 `transfer` と `transferFrom`、ERC-721 `transferFrom` と `safeTransferFrom` の場合、トークンまたは NFT の受取人。ERC-20 と ERC-721 `approve` の場合、承認された支出者。ERC-721 `setApprovalForAll` の場合は、オペレーター。大文字と小文字が混在する EIP-55 チェックサム形式。
`amount_token_scaled`	ETH 転送、ERC-20 転送、承認の場合は、金額。コントラクト呼び出しの場合、呼び出しとともに送信された ETH。ETH が送信されない場合は省略されます。ERC-721 の転送と承認では常に省略されるため、代替可能な利用限度額が NFT トークン ID と一致しません。
`token_symbol`	`"ETH"`: ETH の送金、および ETH を送金するコントラクト呼び出しの場合。Ethereum メインネット、`"USDC"`、`"USDT"`、`"DAI"`、`"WBTC"` で認識されている ERC-20 トークンの場合。他のトークンと ERC-721 オペレーションでは省略されます。
`contract_address`	ERC-20 と ERC-721 の転送と承認の場合は、トークンまたは NFT 契約。コントラクト呼び出しの場合、呼び出されたコントラクト。大文字と小文字が混在する EIP-55 チェックサム形式。ETH 転送の場合は省略されます。
`token_standard`	`"ERC721"`: ERC-721 の転送と承認。ETH 転送、ERC-20 オペレーション、その他のコントラクト呼び出しでは省略されます。
`token_id`	ERC-721 `transferFrom`、`safeTransferFrom`、`approve` の場合、256 ビットの `tokenId` は 10 進数の `String` として表されるため、NFT ID が Cedar の 64 ビットの `Long` をオーバーフローすることはありません。これは `String` であるため、`==` または `in [...]` と等しいかどうかを比較します。`<` と `>` は、数値ではなく文字列を比較します。`setApprovalForAll` と ERC-721 以外のトランザクションでは省略されます。
`from_address`	ERC-721 `transferFrom` と `safeTransferFrom` の場合、現在の所有者（`from`）。大文字と小文字が混在する EIP-55 チェックサム形式。
`approve_all`	ERC-721 `setApprovalForAll(operator, approved)` の場合、`approved` フラグは `Bool` として、コレクション内のすべての NFT に対するオペレーターの承認を付与する場合は `true`、取り消す場合は `false` となります。
`chain_id`	トランザクションのチェーン ID。以前のトランザクションでは省略できるため、`has` で確認してください。
`max_fee_atomic`	ガスリミット × ガスあたりの最大手数料（またはレガシートランザクションのガス価格）（gwei 単位）。

ERC-20 transfer(address, uint256)（0xa9059cbb）の場合、セレクタは ERC-20 に固有です。マルチパーティコンピューティングで認識されないトークンは、トークンに 18 桁の小数があるかのようにスケーリングされます。認識されたトークンを contract_address で照合し、小数点が 18 ではない認識されないトークンに金額制限を設定しないでください。ERC-20 transferFrom と approve は、ERC-721 とセレクタを共有するため、認識されたコントラクトが必要です。これらのセレクタのいずれかを使用して認識されていないコントラクトを呼び出すと、UNRECOGNIZED_PAYLOAD で拒否されます。詳細については、ERC-721 非代替性トークンをご覧ください。

コンテキストには、どの種類の Ethereum トランザクションであるかが記載されていないため、次の点に注意してください。

ETH を送信するコントラクト呼び出しは、ETH の送金のように見えます。どちらにも token_symbol "ETH" と amount_token_scaled があります。コントラクト呼び出しにのみ contract_address があります。ETH 転送のみを許可するには、!(context has contract_address) を追加します。
ERC-20 の承認は ERC-20 の転送に似ています。approve の contract_address、amount_token_scaled、secondary_key（支出者）は、同じアドレスに同じ金額を送金する場合と同じです。転送を許可するポリシーは、承認も許可します。

コントラクト作成トランザクション（to アドレスが空）はデコードできず、UNRECOGNIZED_PAYLOAD で拒否されます。

ERC-721 非代替性トークン

ETHEREUM_TX_V2 で、マルチパーティコンピューティングは次の ERC-721 メソッドをデコードします。

safeTransferFrom(address from, address to, uint256 tokenId) (0x42842e0e)
safeTransferFrom(address from, address to, uint256 tokenId, bytes data) (0xb88d4fde)
transferFrom(address from, address to, uint256 tokenId)（0x23b872dd）
approve(address to, uint256 tokenId)（0x095ea7b3）
setApprovalForAll(address operator, bool approved)（0xa22cb465）

ERC-20 と ERC-721 は、transferFrom（0x23b872dd）と approve（0x095ea7b3）に同じ 4 バイトのセレクタを共有します。uint256 引数が代替可能な金額かトークン ID かを判断するために、マルチパーティコンピューティングは、認識されたトークンコントラクトのレジストリで to コントラクトアドレスを検索します。ERC-721 呼び出しの場合、amount_token_scaled は省略され、token_standard は "ERC721"、token_id は 10 進数の String です。これらの共有セレクタのいずれかを使用した認識されないコントラクトへの呼び出しは、UNRECOGNIZED_PAYLOAD で拒否されます。

EIP-712 型付きデータ

EIP712_TYPED_DATA_V1 ペイロード（types、primaryType、domain、message を含む UTF-8 JSON エンコード EIP-712 型データ）の場合、マルチパーティコンピューティングは JSON 構造を検証し、32 バイトの EIP-712 署名ダイジェスト keccak256(0x1901 ++ domainSeparator ++ hashStruct(message)) を計算します。ここで、++ はバイト連結です。検証では、15 レベルを超えるネスト、循環型、null 配列要素、types.EIP712Domain と一致しない domain フィールドは拒否され、浮動小数点精度の損失なしで 256 ビット整数が保持されます。

EIP712_TYPED_DATA_V1 ペイロードは、次の属性を投影します。

属性	値
`blockchain`	常に `"ETH"` です。
`schema`	常に `"EIP712_TYPED_DATA_V1"` です。
`contract_address`	`domain.verifyingContract`。大文字と小文字が混在する EIP-55 チェックサム形式。ドメインで `verifyingContract` が設定されていない場合は省略されます。
`chain_id`	`Long` による `domain.chainId`ドメインで `chainId` が設定されていない場合は省略されます。
`max_fee_atomic`	常に `0`。型付きデータへの署名ではネットワーク料金が発生しないためです。
`secondary_key`	認識されたメッセージタイプの場合、相手方は ERC-2612 `Permit` と Uniswap `Permit2` の場合は `spender`、ERC-3009 `TransferWithAuthorization` と Safe `SafeTx` の場合は `to` です。その他のメッセージタイプについては、`domain.verifyingContract` をご覧ください。
`amount_token_scaled`	認識されたメッセージタイプ（`Permit`、`Permit2`、`TransferWithAuthorization`、`SafeTx`）の場合、承認されたトークンまたは ETH 値（`value` または `details.amount`）。単位は 10^-9 です。他のメッセージタイプでは省略されます。
`token_symbol`	`"USDC"`、`"USDT"`、`"DAI"`、`"WBTC"`（検証コントラクトまたは Permit2 トークン（`details.token`）が Ethereum メインネットで認識されているトークンの場合）。それ以外の場合は省略されます。
`deadline`	メッセージに `deadline`、`sigDeadline`、`validBefore` フィールドがある場合の、メッセージの有効期限（Unix エポックからの秒数）。それ以外の場合は省略されます。
`eip712`	型付きデータを含む `Record`。詳しくは以下の表をご覧ください。

eip712 レコードには次のフィールドがあります。

フィールド	Cedar タイプ	値
`context.eip712.primary_type`	`String`	`primaryType` 名（例: `"Permit"`、`"PermitSingle"`、`"TransferWithAuthorization"`、`"SafeTx"`）。
`context.eip712.domain`	`Record`	ペイロードが設定する `EIP712Domain` フィールド: `name`、`version`、`chainId`、`verifyingContract`、`salt`。
`context.eip712.message`	`Record`	`message` フィールド。256 ビット整数値（`uint256` と `int256`）は 10 進数の `String` であるため、ルールは 64 ビットオーバーフローなしで正確な値に一致できます。

ビットコイン

次の表に、BITCOIN_TX_V2 ペイロード（BIP 174 PSBT v0）のコンテキスト属性を示します。

属性	値
`secondary_key`	変更されない 1 つの出力のアドレス。すべての出力がおつりである統合の場合、最初の出力のアドレス。
`amount_token_scaled`	`secondary_key` に送信された金額。お釣りは含まれません（1 サトシ = `10`）。統合の場合は `0`。
`token_symbol`	常に `"BTC"` です。
`contract_address`	存在しない。
`chain_id`	PSBT には、どのネットワーク用であるかが示されていないため、存在しません。アドレスは常にメインネットアドレスとしてフォーマットされるため、テストネットアドレスも `bc1`、`1`、`3` のいずれかで始まります。アドレスのプレフィックスは、ネットワークではなくアドレスタイプを示します。
`max_fee_atomic`	マイナー手数料: 合計入力から合計出力を差し引いた額（1 satoshi = `10`）。

Bitcoin ネットワークを分離するには、ネットワークごとに異なる鍵を使用します。たとえば、Mainnet 用の KeyRing と Testnet 用の KeyRing を使用し、principal_keyring または principal_key でルールをスコープします。同じ鍵で両方のネットワークに署名できるため、この方法は、テストネットでメインネットの鍵を使用しない場合にのみ有効です。

お釣りではない複数のアドレスに送信するトランザクションはデコードできません。おつり以外の出力が OP_RETURN 出力のみであるトランザクションなど、送信先アドレスのないトランザクションは評価できません。

Solana

次の表に、SOLANA_TX_V1 ペイロード（署名されていない以前の Solana メッセージまたは v0 Solana メッセージ）のコンテキスト属性を示します。

属性	値
`secondary_key`	SOL 転送の場合、宛先ウォレット。トークン転送の場合、ウォレットではなく、転送先のトークンアカウント。base58 形式。
`amount_token_scaled`	金額。SOL の場合、ランポートの数（1 ランポート = `1`）。トークンの場合、`TransferChecked` 命令が持つ小数でスケーリングされた未加工の金額。
`token_symbol`	SOL 転送の場合は `"SOL"`。トークンの場合は `"USDC"`、`"USDT"`、`"PYUSD"`。その他のミントの場合は省略されます。
`contract_address`	トークン転送の場合、ミントアドレス（base58）。SOL 転送の場合は省略されます。
`chain_id`	存在しません。Solana メッセージではクラスタに名前を付けません。
`max_fee_atomic`	トランザクション全体で支払うことができる lamport の最大額: 必要な署名ごとに 5,000。トランザクションでコンピューティング単位価格が設定されている場合は、優先料金（⌈コンピューティング単位数の上限 × マイクロ lamport 単位のコンピューティング単位価格 ÷ 10⁶⌉）が加算されます。

Solana トランザクションには、複数の命令を含めることができます。

転送手順: システムプログラム Transfer（SOL）、SPL トークンまたは Token-2022 TransferChecked。チェックされていない Transfer 命令と、小数点以下が 9 桁を超えるトークンはデコードできません。
その他の命令: ComputeBudget SetComputeUnitLimit と SetComputeUnitPrice、Memo（v1 と v2）、Associated Token Account Create と CreateIdempotent、System Program AdvanceNonceAccount。これらの命令は独自のコンテキストを生成しません。

各転送指示は、独自のコンテキストで個別に評価されます。トランザクションは、すべての転送が許可されている場合にのみ許可されます。転送が拒否されると、トランザクション全体が拒否されます。max_fee_atomic は取引全体の料金であり、すべてのコンテキストで同じであるため、振替全体で合計しないでください。

トランザクションでコンピューティング単位数の上限を設定せずにコンピューティング単位数の価格を設定した場合、ComputeBudget 命令以外の各命令には、Solana のデフォルトの上限である 200,000 コンピューティング単位数が使用されます（最大 1,400,000）。

トランザクションの署名者は、各命令が署名する必要があるアカウントと一致している必要があります。また、送信元アカウントと移行先のアカウントは書き込み可能である必要があります。アドレスルックアップテーブルを使用する v0 メッセージはデコードできません。署名付きトランザクションエンベロープではなく、署名されていないメッセージバイトを Transaction.payload と Transaction.rawMessage に渡します。

認識されるミントは、Solana メインネットのミントです。Devnet または Testnet では、トークン転送に token_symbol がないため、代わりに contract_address を確認します。

Associated Token Account Create 命令は、新しいアカウントの賃料免除リザーブに SOL で資金を提供します。その金額は amount_token_scaled ではありません。

ルールの例

次の例は、適応可能な permit ポリシーと forbid ポリシーです。各例では、読み取り前に has を使用して、すべてのオプション属性を確認しています。

ペイロードとメタデータを使用した KeyRing の購入上限

開始者がトランザクションに "equities-desk" のラベルを付け、有効期間を 300 秒以下に設定し、値を $500,000 以下に設定した場合、institutional-treasury KeyRing の任意の鍵から Ethereum メインネットで最大 500,000 USDC の buy_transaction 転送を許可します。

permit (
  principal,
  action == Action::"buy_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.principal_keyring == "institutional-treasury" &&
  context.schema == "ETHEREUM_TX_V2" &&
  context has chain_id && context.chain_id == 1 &&
  context has contract_address &&
  context.contract_address == "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" &&
  context has amount_token_scaled && context.amount_token_scaled <= 500000000000000 &&
  context has fiat_amount && context.fiat_amount <= 500000 &&
  context has validity && context.validity <= 300 &&
  context has principal_value1 && context.principal_value1 == "equities-desk"
};

マルチパーティコンピューティングでは、ペイロードに対して fiat_amount がチェックされません。詳細については、コンテキスト属性をご覧ください。

1 つのキーの費用上限

Ethereum メインネット上の 1 つの鍵から最大 1 ETH の ETH 転送を許可します。!(context has contract_address) は、ETH を送信するコントラクト呼び出しを除外します。

permit (principal, action, resource)
when {
  context.principal_keyring == "treasury" &&
  context.principal_key == "hot-wallet-1" &&
  context.schema == "ETHEREUM_TX_V2" &&
  context has chain_id && context.chain_id == 1 &&
  context has token_symbol && context.token_symbol == "ETH" &&
  !(context has contract_address) &&
  context has amount_token_scaled && context.amount_token_scaled <= 1000000000
};

Ethereum のステーブルコインの許可リスト

1 つのアドレスに最大 5,000 USDC の転送を許可し、そのアドレスに最大 5,000 USDC の承認（許容量）を許可します。このポリシーは token_symbol ではなく contract_address をチェックするため、同じシンボルを使用する別のコントラクトのトークンは一致しません。

permit (principal, action, resource)
when {
  context.schema == "ETHEREUM_TX_V2" &&
  context has contract_address &&
  context.contract_address == "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" &&
  context.secondary_key == "0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B" &&
  context has amount_token_scaled && context.amount_token_scaled <= 5000000000000
};

この取引の token_symbol は "USDC" です。

ERC-721 転送とオペレーター承認ガード

承認済みの ERC-721 コントラクトから決済アドレスへの 1 つのトークン化された財務省証券（token_id == "1042"）の転送を許可し、コレクション全体のオペレーター承認（approve_all == true を含む setApprovalForAll）の付与を禁止します。

ポリシー A は、1 つの NFT 転送を許可します。

permit (
  principal,
  action == Action::"internal_transfer_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.schema == "ETHEREUM_TX_V2" &&
  context has chain_id && context.chain_id == 1 &&
  context has token_standard && context.token_standard == "ERC721" &&
  context has contract_address &&
  context.contract_address == "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D" &&
  context has token_id && context.token_id == "1042" &&
  context.secondary_key == "0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B"
};

ポリシー B は、コレクション全体のオペレーター承認を禁止します。

forbid (principal, action, resource)
when {
  context.schema == "ETHEREUM_TX_V2" &&
  context has approve_all && context.approve_all == true
};

EIP-712 ガスレス USDC 許可の上限

承認された決済ルーターに対して、Ethereum メインネットで最大 25,000 USDC のオフチェーン ERC-2612 Permit の署名を許可します。ただし、許可が指定された時間より前に期限切れになる場合に限ります。

permit (
  principal,
  action == Action::"buy_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.schema == "EIP712_TYPED_DATA_V1" &&
  context has chain_id && context.chain_id == 1 &&
  context has contract_address &&
  context.contract_address == "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" &&
  context has eip712 && context.eip712.primary_type == "Permit" &&
  context.secondary_key == "0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45" &&
  context has amount_token_scaled && context.amount_token_scaled <= 25000000000000 &&
  context has deadline && context.deadline <= 1793491200
};

ビットコインの費用上限と手数料の上限

Bitcoin Mainnet でのみ使用する KeyRing の鍵から、最大 10,000 satoshi のマイナー手数料で最大 0.0025 BTC の転送を許可します。

permit (principal, action, resource)
when {
  context.schema == "BITCOIN_TX_V2" &&
  context.principal_keyring == "btc-mainnet" &&
  context has amount_token_scaled && context.amount_token_scaled <= 2500000 &&
  context.max_fee_atomic <= 100000
};

SOL 転送と優先手数料の上限

優先料金を含む合計料金が 50,000 ランポート（0.00005 SOL）以下の場合に、最大 1.5 SOL の SOL 転送を許可します。

permit (principal, action, resource)
when {
  context.schema == "SOLANA_TX_V1" &&
  context has token_symbol && context.token_symbol == "SOL" &&
  !(context has contract_address) &&
  context has amount_token_scaled && context.amount_token_scaled <= 1500000000 &&
  context.max_fee_atomic <= 50000
};

Solana での SPL トークンまたは Token-2022 の転送

1 つのトークンアカウントに最大 250 USDC の送金を許可します。コンテキストには、転送で使用されるプログラムが指定されていないため、同じルールが SPL Token プログラムと Token-2022 プログラムに一致します。

permit (principal, action, resource)
when {
  context.schema == "SOLANA_TX_V1" &&
  context has contract_address &&
  context.contract_address == "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" &&
  context.secondary_key == "9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin" &&
  context has amount_token_scaled && context.amount_token_scaled <= 250000000000
};

secondary_key は、このミントの受取人のトークンアカウントです。受信者ウォレットを許可するには、許可するミントごとにトークンアカウントをリストします。複数の転送を含むトランザクションでは、このルールはすべての転送に一致する必要があります。

認識できないアセットブロック

アセットマルチパーティコンピューティングが認識しない転送を拒否します。この forbid ポリシーは has のみを使用するため、評価に失敗することはありません。

forbid (principal, action, resource)
when { context has amount_token_scaled }
unless { context has token_symbol };

ブロックチェーンの手数料上限

max_fee_atomic は常に存在するため、この forbid ポリシーの評価が失敗することはありません。スケールは各ネイティブコインの 10^-9 であるため、同じ数値でもブロックチェーンごとに値が異なります。ポリシーのスコープを 1 つのブロックチェーンに設定します。

forbid (principal, action, resource)
when { context.blockchain == "ETH" && context.max_fee_atomic > 10000000 };

これにより、0.01 ETH を超える手数料を支払うことができる Ethereum トランザクションが拒否されます。

キーリング

KeyRing は、MPC 鍵（"institutional-treasury" や "btc-cold-storage" など）をグループ化する静的コンテナです。各鍵は単一の KeyRing 内に作成され、その KeyRing に永続的に保持されます。

KeyRing は、次の 3 つの方法でポリシーに参加します。

KeyRing KeyPolicy（署名クォーラム）。KeyRing を作成するときに、不変の KeyPolicy を設定します。これにより、鍵の共有を保持し、KeyRing 内の鍵が署名する前に承認する必要があるチームとユーザーのしきい値ツリーが定義されます。トランザクションポリシーは KeyPolicy と連携して機能します。トランザクションポリシーはペイロード（PERMIT または DENY）のビジネスルールを評価し、KeyRing の KeyPolicy は、署名セレモニーを承認する必要がある鍵共有を管理します。
署名 KeyRing（context.principal_keyring）によるトランザクションポリシーのスコープ設定。すべてのトランザクションのコンテキストには、署名鍵を保持する KeyRing の ID に設定された context.principal_keyring と、署名鍵の ID に設定された context.principal_key が含まれます。context.principal_keyring == "institutional-treasury" を含むルールは、KeyRing 内のすべての鍵（その KeyRing で後で作成された鍵を含む）に適用されます。新しいポリシーを作成または承認する必要はありません。
```
permit (
  principal,
  action == Action::"internal_transfer_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.principal_keyring == "institutional-treasury" &&
  context has fiat_amount && context.fiat_amount <= 100000
};
```
宛先 KeyRing の許可リスト（KeyList 内）。KeyRing を KeyList のエントリとして追加することもできます。これにより、ホット KeyRing とコールド KeyRing 間の内部スイープなど、その KeyRing 内のアクティブな鍵のブロックチェーンアドレスへの転送が、新しい鍵の作成時に自動的に許可されます。例については、KeyList の許可リストと拒否リストをご覧ください。

KeyList の許可リストと拒否リスト

trusted-destinations KeyList のアドレスへの最大 1 ETH の転送のみを許可します。context.key_lists["trusted-destinations"] は、トランザクションの createTime で KeyList が展開されるアドレスのセットです。そのため、エントリを追加または削除すると、新しいポリシーなしでこのルールで許可される内容が変更されます。

// Assuming you created a KeyList with ID "trusted-destinations":
permit (principal, action, resource)
when {
  context.schema == "ETHEREUM_TX_V2" &&
  context has token_symbol && context.token_symbol == "ETH" &&
  !(context has contract_address) &&
  context.key_lists["trusted-destinations"].contains(context.secondary_key) &&
  context has amount_token_scaled && context.amount_token_scaled <= 1000000000
};

すべてのブロックチェーンで、blocked-addresses KeyList のアドレスへのトランザクションを拒否します。key_lists と secondary_key は常に存在し、CreateTransactionPolicy は KeyList が存在することを確認するため、この forbid ポリシーの評価は失敗しません。

// Assuming you created a KeyList with ID "blocked-addresses":
forbid (principal, action, resource)
when { context.key_lists["blocked-addresses"].contains(context.secondary_key) };

KeyList ID は、ドット構文ではなく、ブラケット構文 context.key_lists["..."] で記述します。ドット構文では、ハイフンを含む ID や数字で始まる ID を解析できません。エントリは文字列として比較されるため、各ブロックチェーンのテーブルに記述されているアドレス形式で手動エントリを追加します。詳細については、Cedar コンテキストの KeyList をご覧ください。