bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 75쪽 중 64쪽
-contracts/blob/adb2a382b09ea574f4d18d8af5b6706e8ed9b8f2/src/TokenMessenger.sol#L169)
function to deposit a native token (such as USDC), which delegates to the
**TokenMinter** contract to burn the token. The **TokenMessenger** contract then
sends a message via the
[MessageTransmitter#sendMessage](https://github.com/circlefin/evm-cctp-contracts/blob/adb2a382b09ea574f4d18d8af5b6706e8ed9b8f2/src/MessageTransmitter.sol#L108)
function. After
[sufficient block confirmations](/cctp/v1/required-block-confirmations),
Circle's offchain attestation service, Iris, signs the message. An API consumer
queries this attestation and submits it onchain to the destination domain's
[MessageTransmitter#receiveMessage](https://github.com/circlefin/evm-cctp-contracts/blob/adb2a382b09ea574f4d18d8af5b6706e8ed9b8f2/src/MessageTransmitter.sol#L250)
function. For more details, see
[Quickstart: Cross-chain USDC transfer](/cctp/v1/transfer-usdc-on-testnet-from-ethereum-to-avalanche).
To send an arbitrary message, directly call
[MessageTransmitter#sendMessage](https://github.com/circlefin/evm-cctp-contracts/blob/adb2a382b09ea574f4d18d8af5b6706e8ed9b8f2/src/MessageTransmitter.sol#L108).
Note that the message recipient must implement
[IMessageHandler#handleReceiveMessage](https://github.com/circlefin/evm-cctp-contracts/blob/master/src/interfaces/IMessageHandler.sol#L31C14-L31C34).
<Note>
**Note:**
In CCTP V1, it is not possible to perform a burn-and-mint operation for USDC and
include arbitrary data in the same message. You must include arbitrary data in a
separate message. In later CCTP versions, you can burn-and-mint while including
data in the same message via Hooks.
</Note>
### CCTP V1 on Non-EVM Domains
#### Noble
Noble is a Cosmos application-specific blockchain (or "appchain") that provides
native asset issuance for the Cosmos ecosystem. USDC is natively issued on Noble
and can be transferred via the Inter-Blockchain Communication (IBC) protocol to
other supported appchains in Cosmos, or via CCTP V1 to any supported domain (for
example, Ethereum).
Note that there are key differences between Cosmos appchains like Noble and
EVM-compatible blockchains. Unlike on EVM domains where CCTP V1 is a set of
smart contracts, CCTP V1 on Noble is a Cosmos SDK module, which is deployed by
Noble governance and built into the Noble blockchain. Cosmos appchains can use
IBC to build composable flows with CCTP V1 on Noble. Refer to the
[Noble documentation](/cctp/v1/noble-cosmos-module) for more details.
#### Solana
Solana is a layer-1 blockchain where USDC is natively issued as an SPL-token.
CCTP V1 is deployed to Solana as two Anchor programs: **MessageTransmitter** and
**TokenMessengerMinter**. Developers can compose programs on top of CCTP V1
programs through CPI's (Cross-Program Invocations). Arbitrary messages can be
sent directly by calling `MessageTransmitter#send_message` just as described in
the EVM section above. Refer to the
[Solana documentation](/cctp/v1/solana-programs) for more details.
#### Sui
Sui is another layer-1 blockchain where USDC is natively issued as a
[`Coin` implementation](https://docs.sui.io/standards/coin). CCTP V1 is deployed
to Sui as two programs: **MessageTransmitter** and **TokenMessengerMinter**.
Arbitrary messages can be sent by directly calling
`message_transmitter::send_message` similar to the EVM section above. Refer to
the [Sui documentation](/cctp/v1/sui-packages) for more details.
#### Aptos
Aptos is another layer-1 blockchain where USDC is natively issued as a
[`FA` implementation](https://aptos.dev/en/build/smart-contracts/fungible-asset).
CCTP V1 is deployed to Aptos as two programs: **MessageTransmitter** and
**TokenMessengerMinter**. Arbitrary messages can be sent by directly calling
`message_transmitter::send_message` similar to the EVM section above. Refer to
the [Aptos documentation](/cctp/v1/aptos-packages) for more details.
# CCTP limits V1
Source: https://developers.circle.com/cctp/v1/limits
Limits for CCTP V1 burning and minting
<Warning>
**This is CCTP V1 (Legacy) version. For the latest version, see [CCTP](/cctp)**.
</Warning>
## Minter Allowance
The USDC smart contract (or module) on each blockchain specifies a limit for how
much USDC can be minted before the limit needs to be increased by the master
minter, Circle. This limit is called the "minter allowance" and it is
individually set for each authorized minter, such as CCTP V1.
Minter allowance is decremented each time the authorized minter mints, by the
amount of USDC that is minted. A transaction attempting to mint in excess of the
minter allowance will fail, but may succeed on a subsequent retry after the
minter allowance is reset. Minter allowance can be queried from the USDC
contract on EVM-compatible chains using the public
[minterAllowance](https://github.com/centrehq/centre-tokens/blob/0d3cab14ebd133a83fc834dbd48d0468bdf0b391/contracts/v1/FiatTokenV1.sol#L153)
function. For CCTP V1 on Noble, minter allowance can be queried via the
[fiattokenfactory module minters API](https://github.com/circlefin/noble-fiattokenfactory/blob/33b30a6cf87eba20874df84fa93dd100f71ed512/proto/fiattokenfactory/query.proto#L49-L52).
## Per-Message Burn Limit
CCTP V1 defines per-message burn limits. This value is configurable by Circle.
This limit prevents the situation where a user burns an amount of USDC on a
source chain that could never be minted on a destination chain without
increasing minter allowance thresholds. Per-message burn limits can be queried
on the TokenMinter contract on EVM-compatible chains, using the public
[burnLimitsPerMessage](https://github.com/circlefin/evm-cctp-contracts/blob/master/src/roles/TokenController.sol#L69)
mapping. For CCTP V1 on Noble, the per-message burn limit can be queried via the
[cctp module per\_message\_burn\_limits API](https://github.com/circlefin/noble-fiattokenfactory/blob/33b30a6cf87eba20874df84fa93dd100f71ed512/proto/fiattokenfactory/query.proto#L49-L52).
# CCTP message format V1
Source: https://developers.circle.com/cctp/v1/message-format
Format arbitrary and application-specific messages using CCTP V1
<Warning>
**This is CCTP V1 (Legacy) version. For the latest version, see [CCTP](/cctp)**.
</Warning>
## CCTP V1 Message Header
The top-level message header format is standard for all messages passing through
CCTP V1.
| Field | Offset | Solidity Type | Length (bytes) | Description |
| - | - | - | - | - |
| `version` | 0 | uint32 | 4 | Version identifier - use 0 for CCTP V1 |
| `sourceDomain` | 4 | uint32 | 4 | Source domain ID |
| `destinationDomain` | 8 | uint32 | 4 | Destination domain ID |
| `nonce` | 12 | uint64 | 8 | Unique message nonce (see [Sequential Nonces](#sequential-nonces)) |
| `sender` | 20 | bytes32 | 32 | Address of MessageTransmitter caller on source domain |
| `recipient` | 52 | bytes32 | 32 | Address to handle message body on destination domain |
| `destinationCaller` | 84 | bytes32 | 32 | Address permitted to call MessageTransmitter on destination domain, or bytes32(0) if message can be received by any address |
| `messageBody` | 116 | bytes | dynamic | Application-specific message to be handled by recipient |
### Sequential Nonces
A message nonce is a unique identifier for a message that can only be used once
on the destination domain. In CCTP V1, message nonces are implemented using
**Sequential Nonces**, where the next available nonce on a source domain is an
integer. On the destination domain, messages can be received in any order, and
used nonces are stored as a hash of the source domain and nonce integer value.
<Note>
**Why we use `bytes32` type for addresses**
CCTP V1 is built to support EVM chains, which use 20 byte addresses, and non-EVM
chains, many of which use 32 byte addresses. We provide a
[Message.sol library](https://github.com/circlefin/evm-cctp-contracts/blob/40111601620071988e94e39274c8f48d6f406d6d/src/messages/Message.sol#L145-L157)
as a reference implementation for converting between address and `bytes32` in
Solidity.
</Note>
## CCTP V1 Message Body
The message format includes a dynamically sized `messageBody` field, used for
application-specific messages. For example, TokenMessenger defines a
[BurnMessage](https://github.com/circlefin/evm-cctp-contracts/blob/master/src/messages/BurnMessage.sol)
with data related to cross-chain transfers.
| Field | Offset | Solidity Type | Length (bytes) | Description |
| - | - | - | - | - |
| `version` | 0 | uint32 | 4 | Version identifier (0, for CCTP V1) |
| `burnToken` | 4 | bytes32 | 32 | Address of burned token on source domain |
| `mintRecipient` | 36 | bytes32 | 32 | Address to receive minted tokens on destination domain |
| `amount` | 68 | uint256 | 32 | Amount of burned tokens |
| `messageSender` | 100 | bytes32 | 32 | Address of caller of `depositForBurn` (or `depositForBurnWithCaller`) on source domain |
# CCTP Noble Cosmos module V1
Source: https://developers.circle.com/cctp/v1/noble-cosmos-module
Cosmos SDK Module for CCTP V1 support on Noble
<Warning>
**This is CCTP (Legacy) version. For the latest version, see [CCTP](/cctp)**.
</Warning>
## Overview
Noble is a Cosmos application-specific blockchain (or "appchain") that provides
native asset issuance for the Cosmos ecosystem. USDC is natively issued on Noble
and can be transferred via the Inter-Blockchain Communication Protocol (IBC) to
other supported appchains in Cosmos, or via CCTP V1 to any supported domain (for
example, Ethereum).
Note that there are key differences between Cosmos appchains like Noble and
EVM-compatible blockchains. Unlike on EVM chains where CCTP V1 is a set of smart
contracts, CCTP V1 on Noble is a Cosmos SDK module, which is deployed by Noble
governance and built into the Noble blockchain. Cosmos appchains can use IBC to
build composable flows with CCTP V1 on Noble.
## Testnet and Mainnet Module Address
| Chain | [Domain](/cctp/v1/supported-domains) | Address |
| :- | :- | :- |
| Noble | 4 | noble12l2w4ugfz4m6dd73yysz477jszqnfughxvkss5 |
CCTP V1 on Noble source code is
[available on GitHub](https://github.com/circlefin/noble-cctp). The full message
spec is defined at
[noble-cctp/x/cctp/spec/02\_messages.md](https://github.com/circlefin/noble-cctp/blob/dc81b3e0d566d195c869a213519fcecd38b020a5/x/cctp/spec/02_messages.md).
The interface below serves as a reference for permissionless messaging functions
exposed by the module.
## Module Interface
### depositForBurn
**Message**: `MsgDepositForBurn`
Broadcast a transaction that deposits for burn to a provided domain.
**Arguments**:
* `Amount` - The burn amount
* `DestinationDomain` - Domain of destination chain
* `MintRecipient` - address receiving minted tokens on destination chain as a 32
length byte array
* `BurnToken` - The burn token address on source domain
### depositForBurnWithCaller
**Message**:`MsgDepositForBurnWithCaller`
Broadcast a transaction that deposits for burn with caller to a provided domain.
This message wraps `MsgDepositForBurn`. It adds one extra argument,
`destinationCaller`.
**Arguments**:
* `Amount` - The burn amount
* `DestinationDomain` - Domain of destination chain
* `MintRecipient` - address receiving minted tokens on destination chain as a 32
length byte array
* `BurnToken` - The burn token address on source domain
* `DestinationCaller` - authorized caller as 32 length byte array of
receiveMessage() on destination domain
### replaceDepositForBurn
**Message**: `MsgReplaceDepositForBurn`
Broadcast a transaction that replaces a deposit for burn message. Replace the
mint recipient and/or\
destination caller.
Allows the sender of a previous BurnMessage (created by depositForBurn or
depositForBurnWithCaller)\
to send a new BurnMessage to replace the original. The new BurnMessage will
reuse the amount and\
burn token of the original without requiring a new deposit.
**Arguments**:
* `OriginalMessage`- original message bytes to replace
* `OriginalAttestation`- attestation bytes of `OriginalMessage`
* `NewDestinationCaller` - the new destination caller, which may be the\
same as the original destination caller, a new destination caller, or an
empty\
destination caller, indicating that any destination caller is valid.
* `NewMintRecipient` - the new mint recipient. May be the same as the\
original mint recipient, or different.
### receiveMessage
**Message**: `MsgReceiveMessage`
Broadcast a transaction that receives a provided message from another domain.
After validation, it performs a mint.
**Arguments**:
* `message` [Message format](/cctp/v1/message-format)
* `attestation` - Concatenated 65-byte signature(s) of `message`, in increasing
order\
of the attester address recovered from signatures.
### sendMessage
**Message**:`MsgSendMessage`
Broadcast a transaction that sends a message to a provided domain.
**Arguments**:
* `DestinationDomain` - Domain of destination chain
* `Recipient` - Address of message recipient on destination chain
* `MessageBody` - Raw bytes content of message
### sendMessageWithCaller
**Message**:`MsgSendMessageWithCaller`
Broadcast a transaction that sends a message with a caller to a provided domain.
Specifying a Destination caller requires that only the specified caller can call
`receiveMessage()` on destination domain.
This message wraps `SendMessage` It adds one extra argument,
`DestinationCaller`.
**Arguments**:
* `DestinationDomain` - Domain of destination chain
* `Recipient` - Address of message recipient on destination chain
* `MessageBody` - Raw bytes content of message
* `DestinationCaller` - caller on the destination domain, as 32 length byte
array
### replaceMessage
**Message**: `MsgReplaceMessage`
Broadcast a transaction that replaces a provided message. Replace the message
body and/or destination caller.
**Arguments**:
* `OriginalMessage` - original message bytes to replace
* `OriginalAttestation` - attestation bytes of `OriginalMessage`
* `NewMessageBody` - new message body of replaced message
* `NewDestinationCaller` - the new destination caller, which may be the same as
the original destination caller, a new destination caller, or an empty
destination caller, indicating that any destination caller is valid.
# CCTP block confirmations V1
Source: https://developers.circle.com/cctp/v1/required-block-confirmations
Block confirmation requirements for attestations by chain
<Warning>
**This is CCTP V1 (Legacy) version. For the latest version, see [CCTP](/cctp)**.
</Warning>
Before signing an attestation for a source chain event, Circle waits for a
specified number of onchain block confirmations to achieve
<Tooltip>hard finality</Tooltip>.
The table below shows the average time required for an attestation to become
available after a message is emitted onchain.
<Note>**Note:** These values are subject to change.</Note>
## CCTP V1 Attestation Times
| Source Chain | Number of Blocks | Average Time |
| - | - | - |
| **Ethereum** | \~65\* | \~13 to 19 minutes\* |
| **Avalanche** | 1 | \~8 seconds |
| **OP Mainnet** | \~65 ETH blocks\* | \~13 to 19 minutes\* |
| **Arbitrum** | \~65 ETH blocks\* | \~13 to 19 minutes\* |
| **Noble** | 1 | \~20 seconds |
| **Base** | \~65 ETH blocks\* | \~13 to 19 minutes\* |
| **Polygon PoS** | \~33 | \~75 to 120 seconds |
| **Solana** | 32 | \~25 seconds |
| **Sui** | 1 | \~8 seconds |
| **Aptos** | 1 | \~8 seconds |
| **Unichain** | \~65 ETH blocks\* | \~13 to 19 minutes\* |
<Note>
**Block confirmations for L2s to Ethereum**
Layer 2 (L2) blockchains publish transaction data in batches to Ethereum L1, and
the frequency of these posts varies by chain. Some submit batches every few
minutes, while others are less frequent. After a batch is posted, Circle waits
for the Ethereum L1 block containing the batch to finalize, which typically
happens after \~65 blocks, or 13 to 19 minutes, before issuing an attestation.
</Note>
# CCTP Solana programs and interfaces V1
Source: https://developers.circle.com/cctp/v1/solana-programs
Programs for CCTP V1 support on the Solana blockchain
<Warning>
**This is CCTP V1 (Legacy) version. For the latest version, see
[CCTP](/cctp)**.
</Warning>
## Overview
Solana CCTP V1 programs are written in Rust and leverage the Anchor framework.
The Solana CCTP V1 protocol implementation is split into two programs:
`MessageTransmitter` and `TokenMessengerMinter`. `TokenMessengerMinter`
encapsulates the functionality of both `TokenMessenger` and `TokenMinter`
contracts on EVM chains. To ensure alignment with EVM contracts' logic and
state, and to facilitate future upgrades and maintenance, the code and state of
Solana programs reflect the EVM counterparts as closely as possible.
### Mainnet Program Addresses
| Program | [Domain](/cctp/v1/supported-domains) | Address |
| :- | :- | :- |
| MessageTransmitter | 5 | [`CCTPmbSD7gX1bxKPAmg77w8oFzNFpaQiQUWD43TKaecd`](https://solscan.io/account/CCTPmbSD7gX1bxKPAmg77w8oFzNFpaQiQUWD43TKaecd) |
| TokenMessengerMinter | 5 | [`CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3`](https://solscan.io/account/CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3) |
### Devnet Program Addresses
| Program | [Domain](/cctp/v1/supported-domains) | Address |
| :- | :- | :- |
| MessageTransmitter | 5 | [`CCTPmbSD7gX1bxKPAmg77w8oFzNFpaQiQUWD43TKaecd`](https://solscan.io/account/CCTPmbSD7gX1bxKPAmg77w8oFzNFpaQiQUWD43TKaecd?cluster=devnet) |
| TokenMessengerMinter | 5 | [`CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3`](https://solscan.io/account/CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3?cluster=devnet) |
The Solana CCTP V1 source code is
[available on GitHub](https://github.com/circlefin/solana-cctp-contracts/). The
interface below serves as a reference for permissionless messaging functions
exposed by the programs.
## CCTP V1 Interface
The interface below serves as a reference for permissionless messaging functions
exposed by the `TokenMessengerMinter` and `MessageTransmitter` programs. The
full IDLs can be found onchain using a block explorer.
[MessageTransmitter IDL](https://explorer.solana.com/address/CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3/anchor-program)
and
[TokenMessengerMinter IDL](https://explorer.solana.com/address/CCTPmbSD7gX1bxKPAmg77w8oFzNFpaQiQUWD43TKaecd/anchor-program).
*Please see the instruction rust files or quick-start for PDA information.*
### TokenMessengerMinter
### [depositForBurn](https://github.com/circlefin/solana-cctp-contracts/blob/master/programs/token-messenger-minter/src/token_messenger/instructions/deposit_for_burn.rs)
Deposits and burns tokens from sender to be minted on destination domain. Minted
tokens will be transferred to `mintRecipient`.
**Parameters**
| Field | Type | Description |
| :- | :- | :- |
| amount | u64 | Amount of tokens to deposit and burn. |
| destinationDomain | u32 | Destination domain identifier. |
| mintRecipient | Pubkey | Public Key of token account mint recipient on destination domain. *Address should be the 32 byte version of the hex address in base58. See Additional Notes on `mintRecipient` section for more information.* |
<Note>
**MessageSent event storage**
To ensure persistent and reliable message storage, MessageSent events are stored
in accounts. MessageSent event accounts are generated client-side, passed into
the instruction call, and assigned to have the `MessageTransmitter` program as
the owner. Please see the
[Quickstart Guide](/cctp/v1/transfer-usdc-on-testnet-from-ethereum-to-avalanche)
for how to generate this account and pass it to the instruction call.
For `depositForBurn` messages, this costs `~0.00295104 SOL` in rent. *This rent
is paid by the
[`event_rent_payer`](https://github.com/circlefin/solana-cctp-contracts/blob/master/programs/message-transmitter/src/instructions/send_message.rs#L16C9-L16C25)
account which can be the user or subsidized by a calling program or integrator.*
Once an attestation is available and the message has been received on the
destinatio프로젝트로 돌아가기
