> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/cross-chain-the-distributed-register/messaging-providers.md).
# Messaging providers
The protocol reaches satellite chains through messaging providers, and it is built so that no provider is a protocol-level dependency. A provider connects by exposing an ERC-7786 gateway. Chainlink's interoperability stack, CCIP and CRE, is the default transport of the network. Other providers can be connected as adapters behind the same interface, and each Issuer chooses, among the gateways the network has vetted, the one that carries its asset to each chain.
This page describes what a provider is in the protocol, how one becomes available, how an Issuer chooses and changes it, and what happens when one fails. The mechanics of gateways, routes and peers are described in [Messaging: ERC-7786 gateways, routes and peers](/cross-chain-the-distributed-register/messaging-erc-7786-gateways-routes-and-peers.md).
## What a provider is here
A messaging provider is a network that carries a message from a contract on one chain to a contract on another, and attests who sent it. To the protocol, a provider is a gateway: a contract that implements ERC-7786 on the reference chain, with its counterpart on each satellite it reaches.
```mermaid
flowchart TB
T["Token"] --> I["ERC-7786 interface"]
I --> A1["Adapter: Chainlink
default"]
I --> A2["Adapter: another provider"]
I --> A3["Adapter: another provider"]
A1 --> S1["Satellite A"]
A1 --> S2["Satellite B"]
A2 --> S2
A3 --> S3["Satellite C"]
```
The contracts of the protocol call the interface and nothing below it. They contain no provider-specific code. An adapter is the only place where a provider's own API appears.
## What the protocol requires of a provider
| Requirement | Why |
| ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **It attests the sender.** Each delivered message carries the chain and the address of the contract that sent it. | The token accepts a message only from its peer. Everything else rests on this. |
| **It delivers to a named recipient.** | A validation must reach the T-REX Lite of the asset and no other contract. |
| **It reaches the chain.** The provider supports the satellite, EVM or not. | An asset can only be opened on a chain that a vetted gateway serves. |
| **A delivery that fails can be attempted again.** | The register refuses a settlement in some situations on purpose, for example while the token is paused, and expects it to be delivered later. |
| **Each delivery has a unique identifier.** | The token records what each gateway has delivered and refuses a duplicate. |
The protocol does not require ordered delivery, and it tolerates delay within the reconciliation window of each chain.
## The default: Chainlink
Chainlink's interoperability stack is the default and preferred transport of the network: CCIP, the Cross-Chain Interoperability Protocol, and CRE, the Chainlink Runtime Environment. It is the provider the network vets first and the one an Issuer uses unless it decides otherwise.
Default does not mean exclusive, and it does not mean built on. The protocol is not built on a Chainlink product or on any other provider's. It is built on ERC-7786, and Chainlink is connected through an adapter like any provider would be.
Chainlink also serves the compliance side, apart from messaging: ACE, the Automated Compliance Engine, is used for compliance rules that need a check against data held off-chain.
## How a provider becomes available
| Step | Who | What |
| -------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| 1. An adapter exists | The provider or a third party, under Network governance | An ERC-7786 gateway over the provider, deployed on the reference chain and on the satellites it serves. |
| 2. It is reviewed | Network governance | The adapter and the security model of the provider behind it. |
| 3. It is trusted | The `INTEROP_MANAGER` | The gateway is added to the `TrustedGatewayRegistry`. |
| 4. It is chosen | Each Issuer | The gateway is set as the route of an asset for a chain. |
Steps 1 to 3 happen once per provider. Step 4 is each Issuer's own decision, per asset and per chain. Gateway adapters are governed by Network governance, like the registry that lists them.
## How an Issuer chooses
An Issuer routes each satellite separately.
| Situation | Configuration |
| ---------------------------------------------- | ---------------------------------------------------------------------------------- |
| The default everywhere | Each chain is routed through the Chainlink gateway. |
| A satellite the default does not serve | That chain is routed through a vetted gateway of a provider that serves it. |
| A preference for another provider on one chain | That chain is routed through that provider's gateway. The others keep the default. |
Two limits apply.
* **One route per chain at a time.** An asset has one gateway for a given satellite. It can have different gateways for different satellites.
* **Only vetted gateways.** An Issuer cannot route through a gateway the network has not added to the registry.
## Changing provider
An Issuer changes the provider for a chain by setting a new route.
* Validations issued after the change go out through the new gateway.
* Validations issued before it are settled through the gateway that carried them. The token recorded that gateway when each validation was sent.
* Nothing has to be migrated, and no transfer in progress is lost.
Changing provider is a decision of governance and integration. An adapter has to exist for the new provider, be reviewed and be trusted, and the satellite side has to be reachable through it. It is not a change to the contracts of the protocol.
## Who pays for a message
The caller of the transaction that sends a message pays for it: the account that submits the transaction, or a paymaster that pays on its behalf. This holds on the reference chain, for the transaction that requests a validation or delegates a position, and on a satellite, for the transfer that sends its settlement notification.
## When a provider fails
| Failure | What the protocol does |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Messages are slow.** | Within the reconciliation window, nothing. Beyond it, a settlement that arrives after its validation was discarded is applied and flagged as late. If it breaches a rule, the issuance of validations for that chain is paused. |
| **Messages stop.** | New validations for that chain cannot be delivered and expire. Transfers already executed on the satellite stay reserved on the register until their settlement arrives or the keeper acts. The Issuer can route the chain through another vetted gateway for new validations. |
| **A delivery is duplicated.** | Refused by the token. |
| **A message arrives that the register cannot account for.** | Nothing is applied, and the token pauses itself until an agent has investigated. |
| **The provider or its adapter is compromised.** | The `INTEROP_MANAGER` removes the gateway from the registry. Every route through it is severed at once, for every asset. |
Positions on the reference chain are unaffected by any of these. A holder's tokens on the reference chain move under the two gates as usual, whatever the state of a provider.
## The trust placed in a provider
> **Trust statement.** A vetted gateway is trusted to tell the truth about who sent a message. Within that trust, a faulty gateway could deliver a settlement that no satellite sent, or a validation that the reference chain did not issue. This is the trust assumption of the interoperability solution behind the gateway, and it is as strong as that solution. While the solution works as designed, none of this happens.
The protocol bounds what such a message can do.
* **It must match.** A settlement is accepted only for a validation that was issued, from the chain and the gateway recorded for it, for the wallets it names, within its amount range, and once.
* **It cannot create supply on the register.** No message changes `totalSupply`. Supply changes only by a mint or a burn on the reference chain. Tokens that appeared on a satellite without a recorded position could not circulate: a validation is capped at the position the register records for the sending wallet.
* **Anomalies halt.** A settlement that matches nothing pauses the token.
* **The lever is immediate.** Removing a gateway from the registry takes effect on the next message, for every asset.
These bounds reduce the consequences of a failure. They do not remove the trust. The choice of a provider is a security decision, for the network when it vets a gateway and for the Issuer when it routes through it.
## Statements to avoid
| Statement | What is true |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| "T-REX cross-chain works via Chainlink." | Messaging goes through ERC-7786. Chainlink is the default provider, connected through an adapter. |
| "T-REX is built on" a named bridge or messaging product. | No provider is a protocol-level dependency. |
| "Any provider can be swapped in at will." | A provider needs an adapter, a review by the network and a place in the trusted registry before an Issuer can route through it. |
| "The bridge moves the tokens." | No token crosses a bridge. Messages cross: authorizations one way, reports of execution the other. The register records where each position is active. |
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.t-rex.network/cross-chain-the-distributed-register/messaging-providers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.