# Multi-bridge Message Sender

### Features

* Supports sending messages via multiple bridge sender adapters
* Only a predefined dApp contract can use this multi-bridge sender for cross-chain remote calls
* Allows adding and removing bridge sender adapters
* The caller is responsible for determining the fees to be paid to each of the bridges to be used.
* The caller can choose to omit a set of bridges for a given message
* Emits events for sent messages, sender adapter updates, and error when sending messages

### Functions

#### remoteCall

```solidity
    function remoteCall(
        uint256 _dstChainId,
        address _target,
        bytes calldata _callData,
        uint256 _nativeValue,
        uint256 _expiration,
        address _refundAddress,
        uint256[] calldata _fees,
        uint256 _successThreshold,
        address[] calldata _excludedAdapters
    ) external payable onlyCaller validateExpiration(_expiration)
```

This function allows a remote function to be called on a destination chain. It does this by sending multiple copies of a cross-chain message through available bridges. Only the predefined `caller` contract can call this function. The call is successful if a minimum number of bridge adapters, defined by the `_successThreshold` parameter, successfully dispatch the cross-chain message.

It takes the following parameters:

* `_dstChainId`: The destination chainId
* `_target` is the target execution point on the destination chain
* `_callData` is the data to be sent to \_target by low-level call(eg. address(\_target).call(\_callData))
* `_nativeValue` is the value to be sent to \_target by low-level call (eg. address(\_target).call{value: \_nativeValue}(\_callData))
* `_expiration` refers to the number of seconds that a message remains valid before it is considered stale and can no longer be executed.
* `_refundAddress` refers to the refund address for any extra native tokens paid
* `_fees` refers to the fees to pay to each sender adapter that is not in the exclusion list specified by \_excludedAdapters. The fees are in the same order as the sender adapters in the senderAdapters list, after the exclusion list is applied.
* `_successThreshold` specifies the minimum number of bridges that must successfully dispatch the message for this call to succeed.
* `excludedAdapters` are the sender adapters to be excluded from relaying the message, in ascending order by address

#### addSenderAdapters

```solidity
function addSenderAdapters(address[] calldata _senderAdapters) external onlyOwner
```

Adds an array of bridge sender adapter addresses, that must be provided in ascending order. This function is only callable by the `owner`.

#### removeSenderAdapters

```solidity
function removeSenderAdapters(address[] calldata _senderAdapters) external onlyOwner
```

Removes an array of bridge sender adapter addresses, that must be provided in ascending order. This function is only callable by the predefined `owner` contract.

### Events

* `MultiBridgeMessageSent`: is emitted after a call to `remoteCall()` completes, sending a given message through one or more bridges. The details of this event should be inspected to see if any bridges have failed.&#x20;
* `MessageSendFailed` : is emitted if sending a message through a specific AMB fails.
* `SenderAdapterUpdated`: is emitted when a sender adapter is added or removed

### Dependencies

The contract depends on the following files:

* `IMessageSenderAdapter.sol`: Interface for bridge sender adapters
* `IMultiBridgeMessageReceiver.sol`: Interface for MultiBridgeMessageReceiver contracts on the destination chain
* `MessageSenderGAC`: Global Access Control contract.
* It also uses a `Message.sol` file for the message structure.


---

# 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://multi-message-aggregation.gitbook.io/multi-message-aggregation/core-contracts/multi-bridge-message-sender.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.
