CCIP Service Responsibility

Shared Accountability Model

The Chainlink Cross-Chain Interoperability Protocol (CCIP) is a secure, reliable interoperability protocol for building cross-chain applications and services. Using CCIP involves shared responsibility across multiple participants in the ecosystem, including application developers, blockchain development teams, token developers, Chainlink node operators, and Cross-Chain Verifiers (CCVs).

CCIP provides secure message transport, decentralized verification, and deterministic onchain enforcement. It does not eliminate responsibility for application correctness, blockchain behavior, token configuration, operational monitoring, or choices related to finality, CCVs, executors, and service limits.

Support for a particular blockchain, application, or token does not constitute endorsement of such blockchain, application, or token. Please review the CCIP Service Limits page, which provides important additional information.

Service limits, finality configuration, CCV selection, and execution behavior directly impact system outcomes. All participants are responsible for understanding and managing these factors within their respective domains.

Each participant — application developers, blockchain teams, token developers, node operators, and Cross-Chain Verifiers (CCVs) — plays a distinct role in maintaining system safety and reliability.

Application Developer Responsibilities

Application developers are responsible for the security, correctness, and operational robustness of cross-chain applications built with CCIP. This includes:

Code and application audits: Developers are responsible for auditing their code and applications before deploying to production. Developers must determine the quality of any audits and ensure that they meet the requirements for their application.
CCIP upgrades and best practices: Developers are responsible for following CCIP documentation regarding implementing CCIP upgrades and best practices for integrating CCIP in their applications.
Code dependencies and imports: Developers are responsible for ensuring the quality, reliability, and security of any dependencies or imported packages that they use with Chainlink CCIP, as well as reviewing and auditing these dependencies and packages.
Code quality and testing: Developers are responsible for ensuring that their application code, onchain and offchain, meets the quality expectations and has undergone rigorous testing.
Application monitoring and alerting: Developers must monitor their applications, inform their users of any abnormal activity, and take appropriate action to restore normal operations.
Blockchain risk assessment: Developers are responsible for the risk assessment of any blockchain network where they choose to deploy their application on or decide to interoperate with, when using Chainlink CCIP. This includes choices related to finality. If using the default configuration, this means reviewing the time-to-finality formally documented by a blockchain's development team, understanding how CCIP uses it to determine finality, the nuances in the different types of deterministic finality, and being aware of the risks when CCIP uses block depth to determine chain finality. If they choose to request faster-than-finality (FTF) transfers or otherwise request non-default finality, developers must understand that downstream participants (including receivers, pools, CCVs, and executors) must explicitly support the requested mode, and must consider the reorg risks associated with sending tokens or arbitrary messages before finality. See Execution Latency.
Token risk assessment: Developers are responsible for the risk assessment of any tokens they choose to support or list in their application and expose to their users, including risks associated with faster-than-finality transfers.
CCV risk assessment: Developers are responsible for the risk assessment of any CCVs used in token transfers or arbitrary messages originating from their application, including default, lane-mandated, pool-required, receiver-required, and user-selected CCVs.
Risk communication: Developers must clearly articulate and communicate identified risks to their users, including risks related to finality choices, CCV selection, and execution configuration.
Manual execution: Developers must monitor their CCIP transactions and take action when transactions require manual execution. For example, informing their users and directing them to the appropriate page on the CCIP Explorer and/or by integrating the CCIP API or SDK.
Receiver configuration: Developers are responsible for correctly implementing and configuring their onchain receiver contracts, including whether the receiver implements IAny2EVMMessageReceiverV2. Receivers that do not implement this interface cannot specify custom CCVs or opt in to faster-than-finality transfers. An FTF message sent to a v1 receiver will fail, so developers should ensure they do not use existing v1 receivers for v2 functionality (FTF / CCVs).
CCV and executor selection: Developers are responsible for any CCVs and executors specified in their application's cross-chain messages. Incorrect or incompatible selections may result in stuck or failed transactions, higher fees, or unexpected execution behavior.
Execution gas configuration: Developers are responsible for setting appropriate execution gas limits for their cross-chain messages. Execution gas limits must account for destination-chain execution, CCV verification gas, pool overhead, and any receiver callback logic. Insufficient gas limits may cause failed execution on the destination chain.
Faster-than-finality risk communication: Developers that request faster-than-finality transfers are responsible for communicating the associated reorg risks to their users.

Blockchain Development Team Responsibilities

Blockchain development teams are responsible for the correctness, security, and reliability of their blockchain software. This includes:

Block finality: Blockchain development teams must ensure that blocks with a commitment level of finalized are actually final. The properties of the finality mechanism, including underlying assumptions and conditions under which finality violations could occur, must be clearly documented and communicated to application developers in the blockchain ecosystem. The documented time-to-finality informs how long CCIP waits for finality for outbound transactions from that chain; however, an additional buffer may be added.
Governance model: Blockchain development teams are responsible for setting up a clear and effective governance model and communicating its participants and processes clearly to its stakeholders and application developers.
Fixes and upgrades: Blockchain development teams must communicate availability of fixes immediately and announce planned upgrades as much in advance as possible so blockchain validators and application developers can prepare themselves accordingly.
Incident management: Blockchain development teams are responsible for clearly articulating and communicating any security, reliability and availability incidents to their community. This includes root cause analysis, post-mortem details and a clear plan of action to recover and prevent from happening in the future.
Blockchain liveness: Blockchain development teams must take appropriate action to ensure their blockchain maintains a high degree of liveness and aligns with set expectations towards their community members and applications developers.
Data availability: The blockchain network must ensure that complete historical data remains consistently accessible through standard RPC interfaces. This includes block headers, transactions, and emitted logs. This includes ensuring that nodes can serve past blocks and logs even after temporary downtime or restarts. Failure to provide reliable access to historical logs can result in stuck or failed transactions.

Token Developer Responsibilities

Token Developers may enable token transfers on CCIP for the tokens that they administer. Enabling token transfers on CCIP allows users to transfer tokens between supported blockchains using either Burn and Mint, Lock and Mint, or Lock and Unlock processes. Token Developers who choose to enable token transfers on CCIP are responsible for the correctness, security, and reliability of their token pools, token configurations, and token contracts. This includes:

Code and application audits: Token Developers are responsible for auditing their token contract code and token pool contract code. Developers must determine the quality of any audits and ensure that they meet the requirements for their use cases.
Configuration of CCIP contracts: Token Developers are responsible for maintaining the correct token pool and token administrator for their token in all applicable TokenAdminRegistry contracts. Token Developers are responsible for maintaining control of the address which is set as the token administrator. This token administrator is the only role authorized to map a token to the corresponding token pool on the same network.
CCIP upgrades and best practices: Token Developers are responsible for following CCIP documentation regarding implementing CCIP upgrades and best practices for enabling token transfers on CCIP for their token.
Code dependencies and imports: Token Developers are responsible for ensuring the quality, reliability, and security of any dependencies or imported packages that they use with their token contracts, token pools, or configurations including the TokenAdminRegistry. Token Developers are responsible for reviewing and auditing these dependencies and packages.
Token Developers must retain access to the token administrator account after it has accepted this role in the TokenAdminRegistry. Neither Chainlink Labs nor the Chainlink Foundation is responsible for any loss of access to these token pools, loss of funds, or disruption to applications due to loss of access to these required functions.
Blockchain risk assessment: Token Developers are responsible for the risk assessment of any blockchain network where they choose to deploy their tokens, token pools, and tokens enabled for transfer using Chainlink CCIP. This assessment includes choices related to finality. If using the default configuration, this means reviewing the time-to-finality formally documented by a blockchain's development team, understanding how CCIP uses it to determine finality, the nuances in the different types of deterministic finality, and being aware of the risks when CCIP uses block depth to determine chain finality. If they configure their token pools to support faster-than-finality transfers, or otherwise permit non-default finality for their token, they must consider the reorg and message-number risks associated with enabling transfers before finality. See Execution Latency.
CCV risk assessment: Token Developers are responsible for the risk assessment of any CCVs required for or associated with transfers of their asset, including pool-required CCVs and any token-specific CCVs. If developing and operating their own CCV, see Cross-Chain Verifier Responsibilities below.
Automated Compliance Engine (ACE) integration: Token developers that enable Advanced Pool Hooks using ACE are responsible for the quality, reliability, and security of their Policy Engine and associated policies. Failure to maintain policies or the Policy Engine may cause transfers to revert or remain un-executable.
Risk communication: Token Developers must clearly articulate and communicate identified risks to the users of those tokens including any risks specific to the configuration of tokens enabled for transfer using Chainlink CCIP.
Authorization: Token Developers must verify that they are authorized to create token pools for a given token. Although anyone may create a token pool, the token developer must properly register that token with Chainlink CCIP. Token Developers must also properly configure the TokenAdminRegistry.
Token pool configurations for Rebasable Tokens: Token Developers must properly write the logic in their token pool for burning and minting tokens based on the rebasing mechanism.
Token transfer rate limits: Token Developers must select and configure appropriate token transfer rate limits for tokens on each lane where they choose to enable their token. As of CCIP 2.0, this includes rate limits for custom finality transfers, where applicable.
Token transfer types: Token Developers must select appropriate token transfer type for their tokens; either Burn and Mint, Lock and Mint, or Lock and Unlock. Token Developers are responsible for implementing the burn / mint / transfer functions in their token contracts correctly on all applicable chains.
Pool CCV configuration: Token Developers are responsible for correctly configuring any pool-required CCVs for inbound and outbound transfers, including CCVs specified through Advanced Pool Hooks where applicable.
Pool finality configuration: Token Developers are responsible for configuring the allowed finality supported by their token pools. Token pools do not support faster-than-finality transfers unless explicitly configured to do so.
Migration between CCIP versions: Token Developers who wish to adopt future versions of CCIP are responsible for all migration tasks required to adopt new features and functionality.
Liquidity Management: Token Developers who choose the Lock and Mint or Lock and Unlock mechanism must ensure their token pools have sufficient liquidity when releasing tokens. Failure to maintain adequate liquidity can result in stalled or failed cross-chain transfers, causing a degraded user experience. Token Developers are responsible for:
- Ensuring sufficient liquidity: Continuously monitor transaction volumes and add liquidity to the pool before it is depleted to avoid having user funds stuck in transit.
- Avoiding fragmented liquidity: Where possible, minimize the use of Lock and Unlock across multiple blockchains to reduce operational complexity and prevent liquidity from being split across multiple pools.
- Monitoring liquidity health and automating alerts: Implement monitoring and alerting systems that notify Token Developers when liquidity drops below certain thresholds, allowing for proactive liquidity management before user transfers fail.
- Proper use of provideLiquidity and withdrawLiquidity: Only authorized entities (such as a trusted liquidity manager) should manage liquidity. Ensure all access controls are in place to prevent unauthorized manipulation of the token pool.
Best Practices: Token Developers are responsible for following the appropriate best practices for creating, managing, and enabling transfers of their tokens on Chainlink CCIP.

Although Token Developers may request that their tokens be added to Transporter, tokens may be added to Transporter at any time even if it has not been explicitly requested.

Chainlink Node Operator Responsibilities

Chainlink node operators participate in the decentralized oracle networks (DONs) that power the Committee Cross-Chain Verifiers (CCVs), where applicable, using a configuration specified in the Chainlink software. As participants in these deployments, Node Operators are responsible for the following components of Chainlink CCIP and committee CCV operation:

Node operations: Chainlink node operators must ensure the proper configuration, maintenance, and monitoring of their nodes participating in the Chainlink CCIP**, RMN, and committee CCV infrastructure, where applicable.**
Transaction execution: Chainlink node operators must ensure that transactions execute onchain in a timely manner and that they apply gas bumping when necessary.
Blockchain client: Chainlink node operators are responsible for selecting and properly employing blockchain clients, including latest fixes and upgrades, to connect to supported blockchain networks.
Consensus participation: Chainlink node operators must maintain continuous uptime and active participation in committee CCV verification and execution where applicable.
Committee CCV operation: Chainlink node operators that operate committee CCVs must ensure the proper configuration, maintenance, monitoring, and timely signing of verification results in accordance with applicable Chainlink-defined specifications.
Infrastructure security: Chainlink node operators must follow infrastructure security best practices. These include access control, configuration management, key management, software version & patch management, and (where applicable) physical security of the underlying hardware.
Software version: Chainlink node operators are responsible for ensuring that Chainlink node deployments are running the latest software versions.
Responsiveness: Chainlink node operators must respond to important communication from Chainlink Labs or from other node operators in a timely manner.

Cross-Chain Verifier (CCV) Responsibilities

Cross-Chain Verifiers (CCVs) are responsible for ensuring the quality, reliability, and security of their onchain verifier contracts as well as their offchain verifier implementation. Neither Chainlink Labs nor the Chainlink Foundation is responsible for the development, maintenance, or operation of third-party CCV contracts (other than Chainlink-provided base or reference verifier contract implementations) or third-party offchain verification infrastructure.

Committee CCVs operated by Chainlink node operators are covered under Chainlink Node Operator Responsibilities above.

This section applies to third-party CCV operators, including token developers and other independent operators that develop, maintain, or operate CCV contracts or offchain verification infrastructure.

Following implementation specifications: Failure to adhere to design specifications for the Chainlink-defined VerifierResult API spec and/or verifyMessage function can result in stuck or failed transactions for users, incorrect accounting of token supply, and/or potential loss of tokens.
Maintenance: Failure to maintain up-to-date compatibility with the Chainlink-defined design specifications may result in downtime or unreliable verifications.
Reliability: Verification endpoints must be built to handle user demand, both in terms of transactional capacity and uptime. Failure to respond to verification requests may result in stuck or failed transactions for users and/or potential loss of tokens.
Finality handling: CCV operators are responsible for correctly handling requested finality offchain, including waiting for the appropriate chain state before producing verification results, in accordance with their onchain allowed finality configuration.
Allowed finality configuration: CCV operators are responsible for correctly configuring and maintaining the allowed finality supported by their onchain verifier contracts.
Key management and infrastructure security: CCV operators are responsible for securing signing keys, verification infrastructure, and associated operational systems used to produce verification results.

Disclaimer

Chainlink CCIP is an interoperability messaging protocol. Chainlink does not hold or transfer any assets. The performance and behaviour of applications using Chainlink CCIP may depend on coding, engineering, configuration, and other technical implementation choices made by developers, token issuers, Cross-Chain Verifiers, and other participants. Users remain responsible for evaluating, configuring, testing, deploying, operating, and maintaining their own applications and integrations, including assessing any applicable operational, security, technical, and legal or regulatory risks. Please review the Chainlink Terms of Service which provides important information and disclosures. By using Chainlink CCIP, you expressly acknowledge and agree to accept these terms. Cross-Chain Verifiers (CCVs) may be operated by third parties. The security, availability, governance, and operational profile of a CCV varies depending on the verifier selected. Users are solely responsible for evaluating any CCVs used in connection with their applications or integrations and determining whether they are appropriate for their intended use case. This code represents an example of using a Chainlink product or service. It is provided "AS IS" and "AS AVAILABLE" without warranties of any kind, has not been audited, and may omit checks or error handling. Each party intending to use this reference implementation must perform its own audits, security and code review, and testing before any production deployment and ensure the operation and performance of such code matches expectations. Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node operators are responsible for outcomes due to errors in this example or how it is deployed or operated. Use of the Chainlink Network is subject to the Chainlink Foundation Terms of Service, which provides important information and disclosures. By using this code, you acknowledge and agree to these terms.