# MagpieSymbiosisBridge

The MagpieSymbiosisBridge contract is designed to facilitate cross-chain liquidity aggregation using the Symbiosis bridge, integrating multiple external libraries and interfaces. It inherits from Ownable2Step and Pausable contracts, providing ownership management and pausing capabilities. The contract manages various addresses and mappings to track internal callers, deposits, and configurations. Key features include functions for updating internal callers and addresses, initiating swap transactions with Magpie or user signatures, verifying signatures, and handling inbound and outbound bridging processes. It also includes functions for pausing and unpausing the contract, withdrawing ERC20 tokens, and handling Ether transfers. The contract ensures secure and efficient cross-chain operations with detailed logging and event emission for transparency and traceability.

<table data-full-width="false"><thead><tr><th width="267">Function Name</th><th>Description (Business Logic)</th></tr></thead><tbody><tr><td><mark style="color:red;"><strong>updateInternalCaller</strong></mark> </td><td>The <mark style="color:red;"><strong>updateInternalCaller</strong></mark> function allows the owner to update the list of internal callers, emitting an event to log the changes. The <mark style="color:red;"><strong>updateWeth</strong></mark>, <mark style="color:red;"><strong>updateNetworkIdAndRouterAddress</strong></mark>, <mark style="color:red;"><strong>updatePortalAddress</strong></mark>, <mark style="color:red;"><strong>updateGatewayAddress</strong></mark>, and <mark style="color:red;"><strong>updateGasReceiverAddress</strong></mark> functions enable the owner to update respective addresses and configurations, ensuring the contract can adapt to changes in the underlying infrastructure or requirements.</td></tr><tr><td><mark style="color:red;">swapInWithMagpieSignature</mark> </td><td>The <mark style="color:red;"><strong>swapInWithMagpieSignature</strong></mark> function allows users to initiate a swap transaction using a Magpie signature. This function can only be executed when the contract is not paused, ensuring that operations are halted during maintenance or emergencies. It retrieves swap data using the <mark style="color:red;"><strong>LibRouter.getData</strong></mark> function and then calls the <mark style="color:red;"><strong>swapIn</strong></mark> function with the retrieved data and a boolean flag set to <mark style="color:red;"><strong>true</strong></mark>, indicating that a Magpie signature is being used. The function returns the amount of tokens received from the swap.</td></tr><tr><td><mark style="color:red;"><strong>swapInWithUserSignature</strong></mark> </td><td>The <mark style="color:red;"><strong>swapInWithUserSignature</strong></mark> function, on the other hand, is restricted to internal callers through the <mark style="color:red;"><strong>onlyInternalCaller</strong></mark> modifier. This function also retrieves swap data using LibRouter.getData. However, it includes an additional check to ensure that the <mark style="color:red;"><strong>fromAssetAddress</strong></mark> is not a native asset, reverting the transaction with an <mark style="color:red;"><strong>InvalidAddress</strong></mark> error if this condition is met. The function then calls <mark style="color:red;"><strong>swapIn</strong></mark> with the retrieved data and a boolean flag set to <mark style="color:red;"><strong>false</strong></mark>, indicating that a user signature is being used. It returns the amount of tokens received from the swap.</td></tr><tr><td><mark style="color:red;"><strong>verifySignature</strong></mark> </td><td>The <mark style="color:red;"><strong>verifySignature</strong></mark> function is designed to verify the signature for a swap operation by constructing a message from the provided <mark style="color:red;"><strong>SwapData</strong></mark> and checking it against the expected signature. The function begins by determining the length of the message based on whether the swap includes an affiliate. Using inline assembly, it constructs the message by loading various pieces of data from the calldata into memory, including addresses, amounts, and other relevant details. The function handles both the presence and absence of an affiliate by storing the appropriate keccak256 hash in memory. It then loads data such as <mark style="color:red;"><strong>toAddress</strong></mark>, <mark style="color:red;"><strong>fromAssetAddress</strong></mark>, <mark style="color:red;"><strong>toAssetAddress</strong></mark>, <mark style="color:red;"><strong>amountOutMin</strong></mark>, <mark style="color:red;"><strong>gasFee</strong></mark>, <mark style="color:red;"><strong>recipientNetworkId</strong></mark>, <mark style="color:red;"><strong>recipientAddress</strong></mark>, <mark style="color:red;"><strong>synthesisAddress</strong></mark>, <mark style="color:red;"><strong>symbiosisAddress</strong></mark>, <mark style="color:red;"><strong>bridgeFee</strong></mark>, <mark style="color:red;"><strong>chainId</strong></mark>, and <mark style="color:red;"><strong>clientId</strong></mark> into the message. Additionally, it processes the <mark style="color:red;"><strong>destinationAddress</strong></mark> and <mark style="color:red;"><strong>destinationChain</strong></mark> by copying their lengths and values into memory and computing their keccak256 hashes. Finally, the function calls <mark style="color:red;"><strong>LibRouter.verifySignature</strong></mark> with the constructed message and other parameters to verify the signature. If the signature is valid, it returns the address of the signer, ensuring the integrity and authenticity of the swap operation.</td></tr><tr><td><mark style="color:red;"><strong>swapIn</strong></mark> </td><td>The <mark style="color:red;"><strong>swapIn</strong></mark> function executes an inbound swap operation, handling the entire process from verifying the signature to transferring fees and performing the swap. It begins by incrementing the <mark style="color:red;"><strong>swapSequence</strong></mark> to ensure each swap has a unique identifier. Using inline assembly, it retrieves the <mark style="color:red;"><strong>networkId</strong></mark> and <mark style="color:red;"><strong>routerAddress</strong></mark> from the stored <mark style="color:red;"><strong>networkIdAndRouterAddress</strong></mark> variable. The function then verifies the signature of the swap data using the <mark style="color:red;"><strong>verifySignature</strong></mark> function. If the swap data includes a permit, it calls <mark style="color:red;"><strong>LibRouter.permit</strong></mark> to handle the permit process. It also transfers any associated fees using <mark style="color:red;"><strong>LibRouter.transferFees</strong></mark>. Next, the function prepares the encoded deposit data and calculates its hash. It calls <mark style="color:red;"><strong>LibBridge.swapIn</strong></mark> to perform the actual swap, passing the necessary parameters including the encoded deposit data, the verified address, the router address, and the WETH address. The <mark style="color:red;"><strong>bridgeIn</strong></mark> function is then called to handle the bridging process, including transferring the fee and updating the deposit data hash. Finally, the function checks for reentrancy by comparing the current <mark style="color:red;"><strong>swapSequence</strong></mark> with the incremented value. If they do not match, it reverts the transaction with a <mark style="color:red;"><strong>ReentrancyError</strong></mark>. The function emits a <mark style="color:red;"><strong>BridgeIn</strong></mark> event to log the details of the inbound swap operation.</td></tr><tr><td><mark style="color:red;"><strong>bridgeIn</strong></mark> </td><td>The <mark style="color:red;"><strong>bridgeIn</strong></mark> function facilitates the bridging of an inbound asset transfer into the contract. It takes several parameters, including the transfer fee, refund address, asset address, amount, and a deposit data hash. The function begins by approving the <mark style="color:red;"><strong>portalAddress</strong></mark> to spend the specified amount of the asset. Using inline assembly, it retrieves the bridge fee and other necessary data from the calldata. It constructs a call to the synthesize function, passing in the bridge fee, asset address, amount, receiver address, <mark style="color:red;"><strong>synthesis</strong></mark> address, symbiosis address, refund address, chain ID, and client ID. If the execution of this call fails, the function reverts with a <mark style="color:red;"><strong>SynthesisFailed</strong></mark> error. The function then calls <mark style="color:red;"><strong>dataIn</strong></mark> to handle the transfer fee, deposit data hash, net amount (amount minus bridge fee), asset address, and refund address. Finally, it retrieves the <mark style="color:red;"><strong>crosschainId</strong></mark> from the assembly block and emits a <mark style="color:red;"><strong>BridgeIn</strong></mark> event to log the details of the inbound asset transfer. This ensures that the bridging process is securely executed and properly recorded.</td></tr><tr><td><mark style="color:red;"><strong>dataIn</strong></mark> </td><td>The <mark style="color:red;"><strong>dataIn</strong></mark> function executes an inbound data transfer by taking parameters such as the transfer fee, deposit data hash, amount, asset address, and refund address. It begins by creating a payload and initializing strings for the destination address and chain. Using inline assembly, it retrieves the destination address and chain from the calldata, copies their lengths and values into memory, and constructs the payload with the deposit data hash, amount, and asset address. The function then calls <mark style="color:red;"><strong>IAxelarGasService</strong></mark> to pay the native gas fee for the contract call and <mark style="color:red;"><strong>IAxelarGateway</strong></mark> to execute the contract call to the destination chain and address. If the operation fails, tokens are transferred to the refund address. Finally, the function emits a <mark style="color:red;"><strong>Deposit</strong></mark> event to log the details of the inbound data transfer.</td></tr><tr><td><mark style="color:red;"><strong>execute</strong></mark> </td><td>The <mark style="color:red;"><strong>execute</strong></mark> function handles the execution of cross-chain commands by validating the contract call through the <mark style="color:red;"><strong>IAxelarGateway</strong></mark>. It takes parameters such as the command ID, source chain, source address, and payload. If the validation fails, the function reverts with a <mark style="color:red;"><strong>NotApprovedByGateway</strong></mark> error. Upon successful validation, it calls the <mark style="color:red;"><strong>addDeposit</strong></mark> function to process the payload.</td></tr><tr><td><mark style="color:red;">addDeposit</mark> </td><td>The <mark style="color:red;"><strong>addDeposit</strong></mark> function extracts the deposit data hash, amount, and asset address from the payload using inline assembly and updates the deposit mapping accordingly. It then emits a <mark style="color:red;"><strong>Deposit</strong></mark> event to log the details of the validated deposit, ensuring the integrity and traceability of the cross-chain transaction.</td></tr><tr><td><mark style="color:red;"><strong>swapOut</strong></mark> </td><td>The <mark style="color:red;"><strong>swapOut</strong></mark> function facilitates the outbound swap of assets, restricted to internal callers. It retrieves the network ID and router address using inline assembly, then obtains swap data via <mark style="color:red;"><strong>LibRouter.getData</strong></mark>. The function calculates the deposit data hash and checks the deposit amount. If no deposit is found, it reverts with a <mark style="color:red;"><strong>DepositIsNotFound</strong></mark> error. Otherwise, it resets the deposit amount to zero and calls <mark style="color:red;"><strong>LibBridge.swapOut</strong></mark> to execute the swap, returning the amount received from the swap.</td></tr><tr><td><mark style="color:red;"><strong>multicall</strong></mark> </td><td>The <mark style="color:red;"><strong>multicall</strong></mark> function allows the contract owner to execute multiple delegate calls in a single transaction. It takes an array of calldata, iterates through each item, and performs a delegate call to the contract itself using Address.<mark style="color:red;"><strong>functionDelegateCall</strong></mark>. The results of each call are stored in an array, which is then returned. This function enables batch processing of multiple operations, enhancing efficiency and reducing transaction costs.</td></tr></tbody></table>


---

# 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.fly.trade/developers/fly.trade-contracts/magpiesymbiosisbridge.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.