Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

거래 정책 규칙 작성

이 페이지에서는 트랜잭션 정책에서 확인할 수 있는 속성을 설명하고 이더리움 (ETHEREUM_TX_V2 및 EIP712_TYPED_DATA_V1), 비트코인 (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)은 작업 및 리소스를 참조하세요.

컨텍스트 속성

각 트랜잭션의 컨텍스트에는 페이로드에서 디코딩된 속성, 서명 키 및 키링의 ID, 시작자가 설정하는 메타데이터 속성 (fiat_amount, validity, principal_value1, principal_value2)이 있습니다.

페이로드 속성은 모든 블록체인에서 동일합니다. 다음 표에서는 모든 컨텍스트 속성을 설명하고 Ethereum, Bitcoin, Solana의 표에서는 다자간 계산이 해당 블록체인의 각 속성을 채우는 방법을 설명합니다.

속성	삼나무 유형	항상 표시 여부	값
`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 토큰 계약 또는 호출된 계약 (이더리움), 확인 계약 (EIP-712) 또는 민트 (솔라나)입니다. 네이티브 전송의 경우 생략됩니다.
`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의 `approved` 플래그는 `setApprovalForAll(operator, approved)`를 호출합니다. 운영자 승인을 부여할 때는 `true`, 취소할 때는 `false`입니다.
`deadline`	`Long`	없음	`EIP712_TYPED_DATA_V1` 메시지의 만료 시간(유닉스 시간 이후의 초 단위)으로, `deadline`, `sigDeadline` 또는 `validBefore` 필드에서 가져옵니다.
`eip712`	`Record`	없음	구조화된 EIP-712 페이로드: `primary_type`, `domain`, `message`(256비트 정수를 10진수 문자열로 사용) `EIP712_TYPED_DATA_V1`만 해당됩니다.
`chain_id`	`Long`	없음	EVM 체인 ID입니다(예: 이더리움 메인넷의 경우 `1`, Sepolia의 경우 `11155111`). 이더리움 및 EIP-712만 해당됩니다.
`max_fee_atomic`	`Long`	예	트랜잭션에서 네트워크 수수료로 지불할 수 있는 최대 금액으로, 블록체인 기본 코인의 10^-9 단위입니다. `EIP712_TYPED_DATA_V1`의 경우 `0`입니다.
`payload`	`String`	예	페이로드의 16진수 인코딩 다이제스트입니다(소문자).
`time_stamp`	`Long`	예	거래의 `createTime`(유닉스 시간 이후 경과 시간(초))입니다.
`key_lists`	`Record`/`Set<String>`	예	인스턴스의 각 KeyList ID를 해당 KeyList의 블록체인 주소 `Set<String>`에 매핑하는 레코드입니다(`createTime`에서 확인됨). 인스턴스에 KeyList가 없는 경우 빈 레코드입니다. 대괄호 문법을 사용하여 KeyList를 읽습니다(예: `context.key_lists["trusted-destinations"]`). 자세한 내용은 Cedar 컨텍스트의 KeyList를 참고하세요.

principal_keyring 및 principal_key는 전체 리소스 이름이 아닌 ID입니다. 키 ID는 해당 KeyRing 내에서만 고유합니다. principal_keyring를 선택하여 키링의 모든 키에 규칙을 적용하거나 두 속성을 모두 선택하여 하나의 키 이름을 지정합니다.

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 검사가 없는 규칙은 모든 블록체인에 적용됩니다. 규칙을 하나의 블록체인으로 제한하려면 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.0025BTC (250,000사토시)	`2500000`
1.5SOL (1,500,000,000램포트)	`1500000000`
5,000 USDC	`5000000000000`

ETH와 같이 소수점 이하 자릿수가 9자리 이상인 애셋의 경우 10^-9보다 작은 금액 부분이 삭제됩니다. 규칙으로 확인할 수 없습니다.

이더리움

다음 표에서는 ETHEREUM_TX_V2 페이로드 (EIP-1559를 포함한 RLP 인코딩 기존 및 EIP-2718 트랜잭션)의 컨텍스트 속성을 설명합니다.

속성	값
`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가 전송되지 않으면 생략됩니다. 대체 가능한 지출 한도가 NFT 토큰 ID와 일치하지 않도록 ERC-721 전송 및 승인에서는 항상 생략됩니다.
`token_symbol`	`"ETH"`: ETH 전송 및 ETH를 전송하는 계약 호출 Ethereum Mainnet, `"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에 고유한 ERC-20 transfer(address, uint256) (0xa9059cbb)의 경우 다자간 계산에서 인식하지 못하는 토큰의 금액은 토큰에 소수점 이하 자릿수가 18개인 것처럼 조정됩니다. contract_address로 인식된 토큰을 일치시키고 소수점이 18이 아닌 인식되지 않은 토큰에 금액 한도를 설정하지 않습니다. ERC-20 transferFrom 및 approve는 ERC-721과 선택기를 공유하므로 인식된 계약이 필요합니다. 이러한 선택기 중 하나를 사용하여 인식되지 않은 계약을 호출하면 UNRECOGNIZED_PAYLOAD로 거부됩니다. 자세한 내용은 ERC-721 대체 불가능 토큰을 참고하세요.

컨텍스트에는 어떤 종류의 이더리움 트랜잭션인지 명시되어 있지 않으므로 다음 사항에 유의하세요.

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`	확인 계약 또는 Permit2 토큰 (`details.token`)이 Ethereum Mainnet에서 인식되는 토큰인 경우 `"USDC"`, `"USDT"`, `"DAI"` 또는 `"WBTC"`입니다. 그렇지 않으면 생략됩니다.
`deadline`	메시지에 `deadline`, `sigDeadline` 또는 `validBefore` 필드가 있는 경우 유닉스 시간 이후의 메시지 만료 시간(초)입니다. 그렇지 않으면 생략됩니다.
`eip712`	입력된 데이터가 포함된 `Record`입니다. 자세한 내용은 다음 표를 참조하세요.

eip712 레코드에는 다음 필드가 있습니다.

필드	삼나무 유형	값
`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`	변경되지 않은 출력 하나의 주소입니다. 모든 출력이 변경되는 통합의 경우 첫 번째 출력의 주소입니다.
`amount_token_scaled`	`secondary_key`에 전송된 금액으로, 잔돈은 포함되지 않습니다 (1사토시 = `10`). 통합의 경우 `0`입니다.
`token_symbol`	항상 `"BTC"`입니다.
`contract_address`	표시되지 않습니다.
`chain_id`	PSBT는 어떤 네트워크를 위한 것인지 명시하지 않으므로 표시되지 않습니다. 주소는 항상 메인넷 주소로 형식이 지정되므로 테스트넷 주소도 `bc1`, `1` 또는 `3`로 시작합니다. 주소 프리픽스는 네트워크가 아닌 주소 유형을 표시합니다.
`max_fee_atomic`	채굴자 수수료: 총 입력에서 총 출력을 뺀 값 (1사토시 = `10`)

비트코인 네트워크를 분리하려면 각 네트워크에 서로 다른 키를 사용합니다(예: 메인넷용 키링과 테스트넷용 키링). 그런 다음 principal_keyring 또는 principal_key를 사용하여 규칙을 해당 키로 범위 지정합니다. 동일한 키로 두 네트워크 모두에 서명할 수 있으므로 테스트넷에서 메인넷 키를 사용하지 않는 경우에만 작동합니다.

변경되지 않은 주소 두 개 이상으로 전송하는 트랜잭션은 디코딩할 수 없습니다. 변경되지 않는 유일한 출력이 OP_RETURN 출력인 경우와 같이 전송할 주소가 없는 트랜잭션은 평가할 수 없습니다.

Solana

다음 표에서는 SOLANA_TX_V1 페이로드 (서명되지 않은 기존 또는 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`	전체 트랜잭션에서 램포트로 지불할 수 있는 최대 금액: 필요한 서명당 5,000개에 우선순위 수수료를 더한 금액입니다. 트랜잭션에서 컴퓨팅 단위 가격을 설정하는 경우 ⌈컴퓨팅 단위 한도 × 마이크로 램포트 단위의 컴퓨팅 단위 가격 ÷ 10⁶⌉입니다.

솔라나 트랜잭션에는 여러 명령어가 포함될 수 있습니다.

전송 안내: 시스템 프로그램 Transfer (SOL) 및 SPL 토큰 또는 토큰-2022 TransferChecked 선택 해제된 Transfer 명령어와 소수점 이하 자릿수가 9자리를 초과하는 토큰은 디코딩할 수 없습니다.
기타 안내: ComputeBudget SetComputeUnitLimit 및 SetComputeUnitPrice, 메모 (v1 및 v2), 연결된 토큰 계정 Create 및 CreateIdempotent, 시스템 프로그램 AdvanceNonceAccount 이러한 안내는 자체 컨텍스트를 생성하지 않습니다.

각 전송 안내는 자체 컨텍스트를 사용하여 별도로 평가됩니다. 트랜잭션은 모든 전송이 허용되는 경우에만 허용됩니다. 전송이 거부되면 전체 트랜잭션이 거부됩니다. max_fee_atomic는 전체 트랜잭션에 대한 수수료이며 모든 컨텍스트에서 동일하므로 전송 간에 합산하지 마세요.

트랜잭션에서 컴퓨팅 단위 한도 없이 컴퓨팅 단위 가격을 설정하는 경우 수수료는 ComputeBudget 명령어를 제외한 각 명령어에 대해 Solana 기본 한도인 200,000 컴퓨팅 단위를 사용하며, 최대 1,400,000까지 가능합니다.

트랜잭션의 서명자는 각 명령어가 서명해야 하는 계정과 일치해야 하며 소스 및 대상 계정은 쓰기 가능해야 합니다. 주소 참고표를 사용하는 v0 메시지는 디코딩할 수 없습니다. 서명된 트랜잭션 엔벨로프가 아닌 서명되지 않은 메시지 바이트를 Transaction.payload 및 Transaction.rawMessage에 전달합니다.

인식되는 민트는 Solana 메인넷 민트입니다. Devnet 또는 Testnet에서 토큰 전송에는 token_symbol가 없으므로 대신 contract_address를 확인합니다.

연결된 토큰 계정 Create 명령어는 새 계정의 임대료 면제 준비금을 SOL로 자금을 조달합니다. amount_token_scaled에 없는 금액입니다.

규칙 예

다음 예시는 조정할 수 있는 permit 및 forbid 정책입니다. 각 예시는 선택적 속성을 읽기 전에 has로 모든 선택적 속성을 확인합니다.

페이로드 및 메타데이터를 사용하는 KeyRing의 구매 한도

시작자가 트랜잭션에 "equities-desk" 라벨을 지정하고, 유효성을 최대 300초로 설정하고, 최대 $500,000의 값을 지정하는 경우 institutional-treasury 키링의 모든 키에서 Ethereum Mainnet에서 최대 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 Mainnet의 키 하나에서 최대 1ETH의 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
};

이더리움의 스테이블코인 허용 목록

하나의 주소로 최대 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 계약에서 결제 주소로 토큰화된 국채 (token_id == "1042") 1개를 전송하도록 허용하고 컬렉션 전체 운영자 승인 (approve_all == true가 있는 setApprovalForAll)을 부여하지 못하도록 합니다.

정책 A는 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 허가 한도

승인된 정산 라우터에 대해 이더리움 메인넷에서 최대 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
};

비트코인 지출 한도 및 수수료 한도

비트코인 메인넷에서만 사용하는 KeyRing의 키에서 최대 10,000사토시의 채굴자 수수료로 최대 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 전송

하나의 토큰 계정으로 최대 250 USDC를 전송할 수 있습니다. 컨텍스트에서 전송에 사용되는 프로그램을 지정하지 않으므로 동일한 규칙이 SPL 토큰 및 토큰-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이므로 동일한 숫자가 각 블록체인에서 다른 값입니다. 정책 범위를 하나의 블록체인으로 지정합니다.

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 KeyPolicy (서명 정족수) KeyRing을 만들 때 변경할 수 없는 KeyPolicy를 설정합니다. 이 정책은 키 공유를 보유하고 KeyRing의 키가 서명하기 전에 승인해야 하는 팀 및 사용자의 기준 트리를 정의합니다. 트랜잭션 정책은 KeyPolicy와 함께 작동합니다. 트랜잭션 정책은 페이로드 (PERMIT 또는 DENY)의 비즈니스 규칙을 평가하고 키링의 KeyPolicy는 서명 절차를 승인해야 하는 키 공유를 제어합니다.
서명 키링(context.principal_keyring)으로 트랜잭션 정책 범위 지정. 모든 트랜잭션의 컨텍스트에는 서명 키를 보유하는 키링의 ID로 설정된 context.principal_keyring와 서명 키의 ID로 설정된 context.principal_key가 포함됩니다. context.principal_keyring == "institutional-treasury"가 있는 규칙은 새 정책을 만들거나 승인하지 않고도 해당 키링에서 나중에 생성된 키를 포함하여 키링의 모든 키에 적용됩니다.
```
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의 주소로만 최대 1ETH의 전송을 허용합니다. 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의 경우 점 문법이 파싱되지 않습니다. 항목은 문자열로 비교되므로 각 블록체인의 테이블에 설명된 주소 형식으로 수동 항목을 추가합니다. 자세한 내용은 Cedar 컨텍스트의 KeyList를 참조하세요.