# Chainlink CCIP Bridge

The bridge is the cross-chain transfer module for $USC. It enables the movement of USC between supported blockchain networks using Chainlink’s Cross-Chain Interoperability Protocol (CCIP).

The bridge (powered by Chainlink CCIP - Cross-Chain Interoperability Protocol) is engineered to deliver secure, fully compliant, and highly reliable cross-chain interoperability for $USC transfers across supported networks.

***

### How it Works

The flow starts from the native chain when an account initiates a transaction with inputs:

* The amount of tokens to transfer
* The destination chain
* The recipient address on the destination chain

{% hint style="info" %}
The account also needs a small amount of the source chain’s native token to pay for CCIP routing fees.

Find more at: <https://docs.chain.link/ccip/billing>
{% endhint %}

#### Native Flow

{% stepper %}
{% step %}
**Pre-transfer validation**

* Transfers are not paused
* The transfer amount meets the minimum bridge requirement
* The sender and recipient are not blacklisted
* The destination chain is supported
* A trusted recipient contract is configured for the destination chain
  {% endstep %}

{% step %}
**Token burn on source chain**

Once validated, the specified amount of tokens is permanently burned on the source chain to prevent double-spending.
{% endstep %}

{% step %}
**CCIP message dispatch**

The contract constructs and sends a CCIP message containing:

* The burned token amount
* The recipient address
* The source chain identifier
  {% endstep %}

{% step %}
**Native token refund**

Any unused native tokens provided for CCIP fees are automatically refunded to the user.
{% endstep %}
{% endstepper %}

***

#### Destination Flow

The CCIP Receive function is executed on the destination chain when a CCIP message sent from another chain is delivered by the CCIP router.

This function is responsible for finalizing the cross-chain transfer.

{% stepper %}
{% step %}
**Router authentication**

The function ensures the call is made by the authorized CCIP router contract. Direct calls from any other address are rejected.
{% endstep %}

{% step %}
**Source verification**

The message metadata is checked to confirm:

* The source chain is supported
* The sending contract on the source chain is registered as a trusted remote
  {% endstep %}

{% step %}
**Replay protection**

Each CCIP message includes a unique identifier.\
The contract checks whether this identifier has already been processed and rejects duplicate messages to prevent replay attacks.
{% endstep %}

{% step %}
**Address validation**

All addresses involved in the message (such as the recipient) are checked against blacklist rules.
{% endstep %}

{% step %}
**Token mint**&#x20;

Once all checks pass, the corresponding amount of $USC is minted to the recipient address on the destination chain.
{% endstep %}

{% step %}
**Message finalization**

The message is marked as processed to permanently prevent re-execution.
{% endstep %}
{% endstepper %}

***

### Blacklisting Model

The bridge operates under a blacklist-only compliance model. All addresses are permitted to use the bridge unless explicitly blacklisted.

Blacklist checks are enforced on both the source and destination chains and apply to senders and recipients. Blacklist status is evaluated at execution time to ensure real-time compliance.

In cases where an address becomes blacklisted after a transfer is initiated but before it is finalized on the destination chain, the transfer will fail on the destination chain and may be retried once the restriction is resolved.

***

### Native Fees

Users pay only the native token fees required to execute cross-chain transfers via CCIP.

Fees are calculated dynamically based on current network conditions. If the amount of native tokens provided exceeds the required fee, the excess is automatically refunded to the user.

***

### Supported Networks

The bridge supports multiple blockchain networks, each identified by a CCIP chain selector. Network support is explicitly configured and bidirectional, ensuring secure message exchange between all approved deployments.

***

### Troubleshooting & Recovery

| Scenario                      | Resolution                        |
| ----------------------------- | --------------------------------- |
| Destination execution failure | Verify blacklist status and retry |
| Paused contract               | Wait for unpause                  |
| Failed CCIP execution         | Retry via CCIP UI                 |

Users may monitor and retry transfers using [Chainlink’s CCIP Explorer](https://ccip.chain.link/) and UI.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.colb.finance/payments-core-tech/images-and-media.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.