Sonic
Ethereum
Ink
Berachain
BNB Smart Chain
Base
Polygon
Optimism
Arbitrum
Avalanche
Manta
Polygon zkEVM
zkSync
Blast
Scroll
Linea
Metis
Fantom
As this is an on-chain swap, select the Sonic network and the STS token.
| Contract | Description |
|---|---|
| IAxelarGasService | The IAxelarGasService interface manages gas payments and refunds for cross-chain communication on the Axelar network. It has one function: • payNativeGasForContractCall: pays for gas using native currency for a contract call on a destination chain. |
| IAxelarGateway | The IAxelarGateway interface enables cross-chain communication on the Axelar network. It has two functions: • callContract: executes a remote contract call on a destination chain. • validateContractCall: verifies the authenticity of a contract call and returns a boolean result. |
| IReceiver | The IReceiver interface receives messages on the destination chain and forwards them to the IMessageDestinationHandler. It has one function: • receiveMessage: receives an incoming message, validates the header, and passes the body to the application-specific handler. |
| ILiquidityBridge | The ILiquidityBridge contract defines an interface for a cross-chain liquidity bridge. It specifies several core functions for sending and relaying assets across different blockchain networks, managing transfer status, and handling withdrawals. |
| IMessageBus | The IMessageBus interface facilitates cross-chain message passing and token transfers. It defines structures like SwapInfo (swap details) and SwapRequest (swap operation), and enums such as BridgeSendType (bridge operation types) and TransferType (transfer actions). Core functions include sending and executing messages with transfers, handling refunds, and calculating fees. It supports multiple transfer mechanisms and integrates with a liquidity bridge for cross-chain operations. |
| IOFT | The IOFT interface manages cross-chain token transfers using Omnichain Fungible Tokens (OFT). It defines structures like SendParam for transfer details and MessagingReceipt for transaction receipts. The contract includes functionality for sending tokens across chains, quoting transfer limits and fees, and handling messaging and fee structures. It ensures security through slippage checks and transfer validation. |
| IStargate | The IStargate interface extends the IOFT contract for cross-chain token transfers. It introduces a StargateType enum to define implementation types and a Ticket struct for bus ride operations. Key functionality includes sending tokens across chains via sendToken, which also returns a ticket if bus ride mode is enabled, and retrieving the Stargate type via stargateType(). The interface builds on OFT operations, adding unique Stargate-related logic. |
| IBridge | The IBridge interface defines the core functionality for a token bridge that supports swapping assets across chains. It emits events for swap operations (SwapIn, SwapOut) and allows the contract owner to update internal parameters such as whitelisted callers, WETH address, and network/router details. The multicall function enables executing multiple operations in a single transaction, enhancing operational efficiency. |
| IMagpieCCTPBridge | The IMagpieCCTPBridge interface extends the IBridge contract and adds functionality for cross-chain token and message handling. It allows the owner to update critical addresses such as the CCTP token messenger, Axelar gateway, and gas receiver. Additionally, the interface includes an execute function to handle commands from a source chain, processing them based on the provided command ID, source chain, source address, and encoded payload. This enables seamless communication and execution of cross-chain operations. |
| IMagpieCelerBridgeV2 | The IMagpieCelerBridgeV2 interface extends the IBridge contract, facilitating interactions with the Celer Network. It allows the owner to update the Celer address and includes functions for executing messages with fund transfers and managing refunds. This ensures efficient cross-chain communication and transaction handling. |
| IMagpieRouterV3 | The IMagpieRouterV3 interface provides a framework for managing internal callers and bridges, enabling the owner to update their whitelisted statuses. It includes a multicall function for executing multiple actions in a single transaction, and several token swap methods: swapWithMagpieSignature, swapWithUserSignature, and swapWithoutSignature, each facilitating asset exchanges while returning the amount received. Additionally, it features an estimateSwapGas function to assess gas costs for swaps, enhancing transaction efficiency and cost management. |
| IMagpieStargateBridgeV3 | The IMagpieStargateBridgeV3 interface extends the IBridge contract, enabling management of asset mappings to Stargate pools. It allows the owner to update the asset-to-Stargate and Stargate-to-asset mappings through dedicated functions. Additionally, it includes an updateLzAddress function for modifying the LayerZero address. The interface also features the lzCompose function, enabling Stargate to handle transfers and update deposit amounts, facilitating seamless asset management across the bridge. |
| IMagpieSymbiosisBridge | The IMagpieSymbiosisBridge interface extends the IBridge contract, providing functionalities to manage critical addresses for the Portal, Axelar gateway, and gas receiver, allowing the owner to update these addresses as needed. Additionally, it features an execute function that facilitates the execution of Axelar commands from a source chain, using parameters like command ID, source chain name, source address, and payload. This ensures effective cross-chain communication and command execution. |
| IWETH | The IWETH interface defines essential functions for interacting with Wrapped Ether (WETH). It includes a deposit function to convert Ether to WETH, a transfer function for transferring WETH to a specified address, and a withdraw function for converting WETH back to Ether. This interface facilitates seamless handling of WETH within smart contracts. |
| MagpieCCTPBridge | The MagpieCCTPBridge contract facilitates cross-chain asset swaps and deposits through Circle CCTP bridge. It includes functions for updating router addresses, processing inbound and outbound swaps, and managing deposits. The contract verifies signatures for secure transactions and emits events for asset bridging and deposits. |
| MagpieCelerBridgeV2 | The MagpieCelerBridgeV2 contract enables cross-chain asset swaps and deposits, incorporating security measures like ownership control and pausable functions. It verifies swap signatures, manages deposit data, and facilitates asset bridging through the Celer Network, ensuring efficient transaction handling and refund management. |
| MagpieRouterV3 | The contract is designed to facilitate token swaps. It includes a range of functions for executing commands, handling swaps, and managing gas usage. The contract uses a combination of libraries and interfaces to provide its functionality, including the IOFT interface, LibAsset, LibRouter, and Ownable2Step and Pausable from OpenZeppelin. |
| MagpieStargateBridgeV3 | The MagpieStargateBridgeV3 contract facilitates cross-chain asset swaps and deposits, ensuring security through ownership control and pausable functions. It verifies swap signatures, manages deposit data, and handles asset bridging via the Stargate network. Key functionalities include updating internal callers, executing swaps, and processing deposits while preventing reentrancy and validating addresses. |
| MagpieSymbiosisBridge | The IMagpieSymbiosisBridge interface extends the IBridge contract and introduces functionalities for cross-chain asset transfers and swaps. It enables the owner to update key addresses, including the WETH token, portal, Axelar gateway, and gas receiver, ensuring flexible asset management. The interface features several swap functions, allowing for inbound and outbound asset operations, supported by rigorous signature verification to enhance security. Furthermore, the execute function processes incoming commands from a source chain, validating them through the Axelar gateway before executing the associated payload. This design facilitates efficient cross-chain communication and execution of transactions. |
| LibAsset | The LibAsset library offers utility functions for handling asset transfers, approvals, and balance checks within Ethereum smart contracts. It identifies native assets (Ether) and provides functions to wrap and unwrap assets securely. The library facilitates balance retrieval for both the contract and specific addresses. Additionally, it ensures safe transfer and approval operations for ERC20 tokens using low-level calls with detailed error handling. Key functions include wrap, unwrap, transfer, approve, and permit, enhancing asset management capabilities in cross-chain contexts. |
| LibBridge | The LibBridge library provides essential functions for managing cross-chain swap operations within smart contracts. It computes bridge fees based on the asset type, ensuring accurate financial handling during swaps. The library enables the encoding and decoding of deposit data hashes, facilitating secure data management across different networks. It also incorporates robust error handling for invalid swap conditions and provides methods for both inbound and outbound swap operations. Key functionalities include fee calculation, deposit data encoding, and executing swaps with native and ERC20 assets, optimizing cross-chain transaction processes. |
| LibRouter | The LibRouter library provides functionalities for handling swap operations in smart contracts. It processes incoming data to create a structured SwapData object while validating transaction deadlines. The library facilitates fee transfers, including gas fees and affiliate fees, while managing permissions through an approval mechanism. It verifies signatures to ensure transaction authenticity, utilizing EIP-712 standards for structured data hashing. Key features include getData, transferFees, permit, and verifySignature, enabling robust and secure cross-chain swap functionality. |
| Function Name | Description (Business Logic) |
|---|---|
| verifySignature | The verifySignature function is a private function that verifies the signature for a swap operation. It takes SwapData and a boolean flag useCaller as parameters. The function constructs a message based on the swap details, including whether an affiliate is involved, and uses assembly to efficiently handle the message data. It then calls LibRouter.verifySignature to validate the signature, ensuring the integrity and authenticity of the swap operation. |
| swapIn | The swapIn function is a private function that executes an inbound swap operation. It increments the swapSequence to ensure each swap has a unique sequence number and retrieves the current network ID and router address using assembly. The function verifies the signature of the swap operation through the verifySignature function, ensuring the authenticity of the transaction. If the swap data includes a permit, the function calls LibRouter.permit to handle the permit. It then transfers any associated fees using LibRouter.transferFees. The function prepares the deposit data by filling an encoded data structure and computing its hash. The actual swap is performed by calling LibBridge.swapIn, which returns the amount received from the swap. Finally, the function calls bridgeIn to handle the bridging of assets and checks for reentrancy by comparing the current swap sequence with the initial value. If they do not match, it reverts the transaction with a ReentrancyError. An event BridgeIn is emitted with the deposit data hash and nonce. |
| bridgeIn | The bridgeIn function handles the bridging of an inbound asset transfer into the contract. It approves the token messenger to spend the specified amount of the asset and prepares the data for the bridging operation using assembly. The function calls tokenMessengerAddress.execute to perform the bridging operation and reverts with BurnFailed if the operation fails. It then calls dataIn to handle the inbound data transfer and emits a BridgeIn event with the deposit data hash and nonce. |
| dataIn | The dataIn function executes an inbound data transfer, preparing the payload with the deposit data hash, amount, and asset address. It calls IAxelarGasService.payNativeGasForContractCall to pay the gas fee for the contract call and IAxelarGateway.callContract to execute the contract call on the destination chain. |
| execute | The execute function handles the execution of inbound messages from the Axelar gateway. It validates the contract call using IAxelarGateway.validateContractCall and reverts with NotApprovedByGateway if the validation fails. The function then calls addDeposit to add the validated deposit. |
| addDeposit | The addDeposit function adds a validated deposit to the contract, updating the deposit mapping with the amount and asset address from the payload. It emits a Deposit event with the deposit data hash and amount. |
| swapOut | The swapOut function handles outbound swap operations, restricted to internal callers. It retrieves the network ID and router address using assembly and prepares the message and attestation data for the swap. The function calls IReceiver.receiveMessage to process the message and reverts with MintFailed if the operation fails. It then retrieves the deposit amount from the deposit mapping and performs the swap using LibBridge.swapOut, returning the amount received from the swap. |
| multicall | The multicall function allows the contract owner to execute multiple function calls in a single transaction. It iterates over the provided data array and calls each function using Address.functionDelegateCall, returning the results of each call. |
| receive | receive function handles incoming Ether transfers. |
| Function Name | Description (Business Logic) |
|---|---|
| swapInWithMagpieSignature | The swapInWithMagpieSignature function handles swap operations and can be called by anyone when the contract is not paused. It utilizes the LibRouter library to retrieve the necessary swap data and execute the swap. This function ensures that the swap operation is performed correctly, including any additional checks required for native assets. |
| swapInWithUserSignature | The swapInWithUserSignature function also handles swap operations but is restricted to internal callers. Like swapInWithMagpieSignature, it uses the LibRouter library to retrieve swap data and execute the swap. This function includes additional checks specifically for native assets to ensure the integrity and security of the swap operation. |
| verifySignature | The verifySignature function is responsible for verifying the signature of a swap operation. This function takes in a SwapData struct, which contains the details of the swap, and a boolean flag useCaller that indicates whether the caller’s address should be used for verification. The function begins by determining the length of the message based on whether the swap includes an affiliate. It then uses inline assembly to construct the message that will be hashed and verified. The message includes various parameters such as the source and destination addresses, asset details, amounts, and network IDs. The assembly code dynamically allocates memory for the message and populates it with the relevant data from the swapData struct. Depending on whether an affiliate is involved, it uses different keccak256 hash values to identify the type of swap. Finally, the function calls LibRouter.verifySignature with the constructed message and other parameters to verify the signature. If the signature is valid, it returns the address of the signer. |
| swapIn | The swapIn function executes a swap operation. It takes a SwapData struct and a boolean flag useCaller as parameters and returns the amount received from the swap operation. The function begins by incrementing the swapSequence to track the current swap operation. It then retrieves the network ID and router address from the stored networkIdAndRouterAddress using inline assembly. Next, the function verifies the signature of the swap operation by calling the verifySignature function. If the swap data includes a permit, it calls LibRouter.permit to handle the permit. It also transfers any associated fees using LibRouter.transferFees. The function then prepares the deposit data by creating a new byte array and filling it with the necessary information using LibBridge.fillEncodedDepositData. It calculates the hash of the deposit data and stores the refund address in the refundAddresses mapping. The actual swap operation is performed by calling LibBridge.swapIn, which returns the output amount. The function then calls bridgeIn to handle the bridging of assets, passing the necessary parameters including the fee, asset address, output amount, deposit data hash, and current swap sequence. Finally, the function checks for reentrancy by comparing the current swap sequence with the stored swapSequence. If they do not match, it reverts with a ReentrancyError. |
| bridgeIn | The bridgeIn function in the MagpieCelerBridgeV2 contract handles the bridging of an inbound asset transfer into the contract. It takes several parameters, including the bridge fee, the address of the asset being bridged, the amount of the asset, the encoded hash related to the cross-chain transaction, and the current swap sequence. The function begins by creating an instance of the IMessageBus interface using the stored celerAddress. It retrieves the address of the liquidity bridge from the message bus. If the asset being bridged is not a native token, it approves the liquidity bridge to transfer the specified amount. Next, the function uses inline assembly to extract the receiver address, chain ID, and slippage from the calldata. These values are necessary for the bridging operation. It then calls the send method of the ILiquidityBridge interface, passing the receiver address, asset address, amount, chain ID, current swap sequence, and slippage. This method handles the actual transfer of assets across chains. To ensure the transaction is tracked, the function calculates a transferId by hashing various parameters, including the contract address, receiver address, asset address, amount, chain ID, current swap sequence, and the current chain Id. Finally, the function calls sendMessageWithTransfer on the message bus, passing the bridge fee, receiver address, chain ID, liquidity bridge address, transfer ID, and the encoded deposit data hash. This method sends a message along with the transfer to ensure the transaction is properly recorded and processed. |
| swapOut | The swapOut function in the MagpieCelerBridgeV2 contract handles the outbound swap operation. It is restricted to internal callers and returns the amount received from the swap. The function retrieves the network ID and router address using inline assembly and then gets the swap data from LibRouter. It calculates the deposit data hash and retrieves the deposit amount. If the deposit amount is zero and the asset is native, it unwraps the WETH and updates the deposit amount. The function then calls LibBridge.swapOut to perform the swap and returns the output amount. |
| executeMessageWithTransfer | The executeMessageWithTransfer function processes inbound messages with asset transfers. It decodes the deposit data hash from the payload and updates the deposit mapping with the received amount. An event is emitted to log the deposit, and the function returns a success status. |
| executeMessageWithTransferRefund | The executeMessageWithTransferRefund function handles refunds for failed transfers. It decodes the deposit data hash and retrieves the refund address. If the refund address is invalid, it reverts. The function then transfers the refund amount to the receiver and emits a refund event. It returns a success status. |
| Multicall | The multicall function allows the contract owner to execute multiple function calls in a single transaction. It iterates over the provided data array, executing each call using Address.functionDelegateCall, and returns the results. |
| receive | receive function handles incoming Ether transfers. |
| Function Name | Description (Business Logic) |
|---|---|
| updateInternalCaller | The updateInternalCaller function allows the contract owner to update the list of authorized internal callers, emitting an UpdateInternalCaller event upon execution. Similarly, the updateBridge function updates the list of authorized bridge addresses and emits an UpdateBridge event. |
| multicall | The multicall function enables the contract owner to execute multiple delegate calls in a single transaction. It iterates over an array of calldata, performing each delegate call and storing the results in an array, which is then returned. This function enhances the contract’s efficiency by allowing batch processing of multiple operations. |
| fallback | It includes a fallback function designed to handle uniswapV3SwapCallback requests from any protocol based on UniswapV3. This function does not check for the factory since the contract is not intended to store tokens. Instead, it protects the user by ensuring the amountOutMin check is performed at the end of execution by comparing the starting and final balances at the destination address. The function uses inline assembly to extract parameters from the calldata, such as amount0Delta, amount1Delta, and assetIn. If the calldata size is not 164 bytes or if both amount0Delta and amount1Delta are non-positive, the function reverts with appropriate errors. The function then transfers the calculated amount of assetIn to the caller. |
| getFromAddress | The getFromAddress function retrieves the address to be used for a swap operation. It takes swapData, a boolean useCaller, and a boolean checkSignature as parameters. If checkSignature is true, the function constructs a message based on whether the swap data includes an affiliate and verifies the signature using the LibRouter.verifySignature function. If the signature is valid, it returns the address from the swap data. If checkSignature is false and useCaller is true, it returns the caller’s address. Otherwise, it reverts with an InvalidCall error. This function ensures that the correct address is used for the swap operation, providing flexibility and security in handling swap requests. |
| swap | The swap function facilitates token swaps based on the provided swapData. It takes the address initiating the swap (fromAddress) and the full amount used for the operation (fullAmountIn). The function calculates the initial balance of the destination address (toAddress) for the output asset (toAssetAddress). It then executes the swap by calling the execute function, which returns the amount transferred and the gas used. The function calculates the final balance of the destination address and determines the amount of tokens received (amountOut). If the received amount is less than the minimum required (amountOutMin), it reverts with an InsufficientAmountOut error. Additionally, it checks if the input amount matches the transferred amount for non-native assets, reverting with an InvalidAmountIn error if they do not match. If fullAmountIn is greater than zero, it emits a Swap event with the relevant details. |
| estimateSwapGas | The estimateSwapGas function estimates the gas required for a swap operation. It retrieves the swap data using LibRouter.getData() and determines the address initiating the swap. If the swap data includes a permit, it calls LibRouter.permit to handle the permit. It then transfers any applicable fees using LibRouter.transferFees. Finally, it calls the swap function and returns the amount of tokens received and the gas used. |
| swapWithMagpieSignature | The swapWithMagpieSignature function performs a swap operation using Magpie signature. It retrieves the swap data and the address initiating the swap, handles any permits, transfers fees, and calls the swap function. It returns the amount of tokens received. |
| swapWithUserSignature | The swapWithUserSignature function allows internal callers to perform a swap operation using a user-provided signature. It retrieves the swap data and the address initiating the swap, ensuring no native tokens are sent with the transaction. It handles any permits, transfers fees, and calls the swap function, returning the amount of tokens received. |
| swapWithoutSignature | The swapWithoutSignature function enables bridge addresses to perform a swap operation without requiring a signature. It retrieves the swap data and the address initiating the swap, then calls the swap function, returning the amount of tokens received. This function is restricted to authorized bridge addresses using the onlyBridge modifier. |
| getCommandData | The getCommandData function prepares the necessary command data for iterating through a sequence of commands. It uses inline assembly to calculate the offsets and lengths required for processing the commands. Specifically, it calculates the commandsOffset by adding 70 to the shifted value of the calldata at position 68, the commandsOffsetEnd by adding 68 to the calldata at position 36, and the outputsLength by shifting the calldata at position 70. These values are essential for correctly iterating through the commands during the swap operation. |
| execute | The execute function handles the execution of a sequence of commands for the swap operation. It takes the address from which the assets will be swapped (fromAddress) and the address of the asset to be swapped (fromAssetAddress). The function retrieves the command data using getCommandData and initializes a pointer for the output data. It then iterates through the commands using a loop, calling the executeCommand function for each command. The executeCommand function returns the amount transferred, the gas used, and updates the output pointer. If the final output pointer exceeds the allocated output length, the function reverts with an InvalidOutput error. This function ensures that the swap operation is executed correctly and efficiently, handling multiple commands in a single transaction. |
| getInput | The getInput function constructs the input data for a specific command based on its position (i) and the memory pointer of the currently available output (outputPtr). Using inline assembly, the function calculates the end position of the sequences and initializes the input data and native token amount. It iterates through the sequences, processing each one based on its type, such as NativeAmount, Selector, Address, Amount, Data, CommandOutput, RouterAddress, and SenderAddress. For each sequence type, the function performs specific operations: • For NativeAmount, it determines the native token amount either from the output pointer or directly from the calldata. • For Selector, it loads the function selector from the calldata. • For Address, it extracts the address from the calldata. • For Amount, it calculates the amount from the calldata. • For Data, it copies the data from the calldata to the input. • For CommandOutput, it loads the output data from the output pointer. • For RouterAddress, it stores the contract’s address. • For SenderAddress, it stores the caller’s address. If an invalid sequence type is encountered, the function reverts with an InvalidSequenceType error. After processing all sequences, it updates the input data length and the free memory pointer. This function ensures that the input data for each command is correctly constructed, enabling the execution of complex operations within the contract. |
| executeCommandCall | The executeCommandCall function executes a command call with the given parameters. It retrieves the input data and native token amount using the getInput function. The function then calculates the output length from the calldata and uses a switch statement to handle different selectors. If the selector is invalid or corresponds to a blacklisted transferFrom call, the function reverts with appropriate errors. For valid selectors, it retrieves the target address from the calldata and ensures it is not the contract’s address. It then performs a call to the target address with the provided input data and native amount. If the call fails, it reverts with the returned data. The function updates the output offset pointer and returns the new position. |
| executeCommandApproval | The executeCommandApproval function handles the execution of a command approval. It retrieves the input data using the getInput function and extracts the self address, spender address, and the amount to be approved from the input data. The function then calls the approve method on the self address, allowing the spender to spend the specified amount. This function ensures that the approval operation is executed correctly, enabling subsequent transactions to utilize the approved amount. |
| executeCommandTransferFrom | The executeCommandTransferFrom function facilitates the execution of a transfer command from a specific address and asset. It retrieves the input data using the getInput function and extracts the amount to be transferred from the input data. If the amount is greater than zero, it also extracts the recipient address and performs the transfer from the specified fromAddress to the recipient using the transferFrom method of the fromAssetAddress. The function then updates the accumulated transfer amount and returns it. This ensures that the specified amount of the asset is correctly transferred from the source address to the destination address. |
| executeCommandTransfer | The executeCommandTransfer function handles the execution of a direct transfer command. It retrieves the input data using the getInput function and extracts the amount to be transferred. If the amount is greater than zero, it also extracts the sender (self) and recipient addresses from the input data. The function then performs the transfer from the sender to the recipient using the transfer method. This function ensures that the specified amount is correctly transferred from the sender to the recipient, facilitating the movement of assets within the contract. |
| executeCommandWrap | The executeCommandWrap function handles the execution of a wrap command, which is used to wrap native tokens. It retrieves the input data using the getInput function and extracts the self address and the amount to be wrapped from the input data. The function then calls the wrap method on the self address with the specified amount, ensuring that the native tokens are correctly wrapped. |
| executeCommandUnwrap | The executeCommandUnwrap function is responsible for executing an unwrap command, which is used to unwrap native tokens. Similar to the wrap function, it retrieves the input data and extracts the self address and the amount to be unwrapped. The function then calls the unwrap method on the self address with the specified amount, ensuring that the native tokens are correctly unwrapped. |
| executeCommandBalance | The executeCommandBalance function executes a balance command and returns the resulting balance. It retrieves the input data using the getInput function and extracts the self address. The function then calls the getBalance method on the self address to retrieve the balance. The balance is stored at the output offset pointer in memory, and the function updates the output offset pointer before returning it. This function ensures that the balance of the specified address is correctly retrieved and stored for further use in the contract. |
| executeCommandMath | The executeCommandMath function executes a mathematical command based on the provided parameters. It retrieves the input data using the getInput function and defines a nested assembly function, math, to perform various mathematical operations. The function iterates through a set of commands, processing each one based on its operator type, such as addition, subtraction, multiplication, division, power, absolute value (both 128-bit and 256-bit), bitwise shift right, and bitwise shift left. For each operator, the function retrieves the operands from either the current output pointer or the input data, performs the specified operation, and stores the result in the current output pointer. If an invalid operator is encountered, the function reverts with an InvalidSequenceType error. After processing all commands, the function updates the output offset pointer and returns it. This function ensures that complex mathematical operations can be executed efficiently within the contract, supporting a wide range of arithmetic and bitwise operations. |
| executeCommandComparison | The executeCommandComparison function executes a comparison command based on the provided parameters. It retrieves the input data using the getInput function and defines a nested assembly function, comparison, to perform various comparison operations. The function iterates through a set of commands, processing each one based on its operator type, such as less than (Lt), less than or equal to (Lte), greater than (Gt), greater than or equal to (Gte), equal to (Eq), and not equal to (Ne). For each operator, the function retrieves the operands from either the current output pointer or the input data, performs the specified comparison, and stores the result in the current output pointer. If an invalid operator is encountered, the function reverts with an InvalidSequenceType error. After processing all commands, the function updates the output offset pointer and returns it. This function ensures that complex comparison operations can be executed efficiently within the contract, supporting a wide range of relational operations to facilitate decision-making processes in the contract’s logic. |
| executeCommand | The executeCommand function is a comprehensive handler for executing various commands within the swap operation. It takes several parameters, including the command data position (i), the address from which assets will be transferred (fromAddress), the asset address (fromAssetAddress), and pointers for output memory (outputPtr and outputOffsetPtr). It also tracks the accumulated transferred amount (transferFromAmount) and the gas used (gasUsed). The function begins by determining the type of command to execute using the CommandAction enumeration. Depending on the command type, it calls the appropriate function to handle the command: • Call: Executes a generic function call using executeCommandCall. • Approval: Handles token approval operations with executeCommandApproval. • TransferFrom: Executes a transfer from a specific address using executeCommandTransferFrom. • Transfer: Executes a direct transfer with executeCommandTransfer. • Wrap: Wraps native tokens using executeCommandWrap. • Unwrap: Unwraps native tokens with executeCommandUnwrap. • Balance: Retrieves the balance of an address using executeCommandBalance. • Math: Performs mathematical operations with executeCommandMath. • Comparison: Executes comparison operations using executeCommandComparison. • EstimateGasStart: Records the starting gas for estimation. • EstimateGasEnd: Calculates the gas used by subtracting the remaining gas from the starting gas. If an invalid command is encountered, the function reverts with an InvalidCommand error. The function returns the updated values for transferFromAmount, gasUsed, and outputOffsetPtr, ensuring that the swap operation is executed correctly and efficiently. |
| receive | receive function handles incoming Ether transfers. |
| Function Name | Description (Business Logic) |
|---|---|
| updateInternalCaller | The updateInternalCaller function allows the owner to update the internal caller list, emitting an UpdateInternalCaller event upon changes. The updateWeth function allows the owner to update the WETH address. The updateNetworkIdAndRouterAddress function allows the owner to update the network ID and router address. The updateAssetToStargate and updateStargateToAsset functions allow the owner to update the mappings between assets and Stargate addresses, emitting corresponding events. The updateLzAddress function allows the owner to update the LayerZero address. |
| swapInWithMagpieSignature | The swapInWithMagpieSignature function allows users to perform a swap operation using a Magpie signature. This function can be called externally and requires a calldata parameter. It is payable and can only be executed when the contract is not paused. The function retrieves swap data using the LibRouter.getData method and then calls the swapIn function with the retrieved data and a boolean flag set to true, indicating that the swap is performed with a Magpie signature. The function returns the amount of output tokens received from the swap. |
| swapInWithUserSignature | The swapInWithUserSignature function is similar but is restricted to internal callers only, as enforced by the onlyInternalCaller modifier. This function also retrieves swap data using the LibRouter.getData method. However, it includes an additional check to ensure that the fromAssetAddress in the swap data is not a native asset, reverting with an InvalidAddress error if this condition is met. The function then calls the swapIn function with the retrieved data and a boolean flag set to false, indicating that the swap is performed with a user signature. The function returns the amount of output tokens received from the swap. |
| verifySignature | The verifySignature function is a private view function that verifies the signature for a swap operation. It takes two parameters: swapData, which is a struct containing the details of the swap, and useCaller, a boolean flag indicating whether to use the caller’s address for verification. The function returns the address of the signer if the signature is valid. The function begins by determining the length of the message based on whether the swap data includes an affiliate. It then uses inline assembly to construct the message that will be hashed and verified. Depending on the presence of an affiliate, it stores the appropriate keccak256 hash of the swap message structure in memory. The function then loads various fields from the calldata into memory, including addresses and amounts related to the swap. Finally, the function calls LibRouter.verifySignature with the constructed message and other relevant parameters to verify the signature. If the signature is valid, the function returns the address of the signer. |
| swapIn | The swapIn function executes an inbound swap operation. It increments the swapSequence and stores the current sequence. Using inline assembly, it retrieves the network ID and router address from the networkIdAndRouterAddress state variable. The function then verifies the signature of the swap data using the verifySignature function. If the swap data includes a permit, it calls LibRouter.permit to handle the permit. It also transfers any applicable fees using LibRouter.transferFees. The function constructs the encoded deposit data and calculates its hash. It then calls LibBridge.swapIn to perform the swap and subsequently calls bridgeIn to handle the bridging process. If the swapSequence has changed during execution, it reverts with a ReentrancyError. |
| getExtraOptions | The getExtraOptions function retrieves extra options for the SendParam struct, encoding them as bytes. It constructs the options with a gas limit and returns the encoded bytes. |
| getSendParam | The getSendParam function constructs a SendParam struct with the specified amount and encoded deposit data hash. It uses inline assembly to retrieve the receiver address, destination endpoint ID, and gas limit from the calldata. It then returns the constructed SendParam struct, including the extra options and encoded deposit data hash. |
| bridgeIn | The bridgeIn function facilitates the inbound transfer of assets into the contract. It takes several parameters, including the bridge fee, refund address, target asset address, amount, and a deposit data hash. The function first retrieves the corresponding Stargate address for the asset. If the address is invalid, it reverts with an InvalidStargateAddress error. It calculates the total value to send, including the bridge fee and, if the asset is native, the amount. For non-native assets, it approves the transfer to the Stargate address. The function constructs a SendParam struct using the getSendParam function and then interacts with the Stargate contract to quote the amount received and send the token, including the bridge fee and refund address. |
| swapOut | The swapOut function allows internal callers to execute an outbound swap operation. It retrieves the network ID and router address using inline assembly. The function then obtains swap data and calculates the deposit data hash. It checks if the deposit amount is available; if not, it reverts with a DepositIsNotFound error. The function resets the deposit amount to zero and calls LibBridge.swapOut to perform the swap, returning the amount of output tokens received. |
| getDepositAmount | The getDepositAmount function is a private pure function that extracts and returns the deposit amount from an encoded bytes array. It uses inline assembly to load the amount from the specified position in the bytes array. |
| lzCompose | The lzCompose function handles the composition of LayerZero messages. It verifies the sender and the asset address, ensuring they match the expected values. If the checks pass, it decodes the deposit data hash from the message and updates the deposit amount for the corresponding asset. The function emits a Deposit event with the deposit data hash and the updated deposit amount. |
| multicall | The multicall function allows the contract owner to execute multiple function calls in a single transaction. It takes an array of calldata and iterates through each element, performing a delegate call to the contract itself. The results of each call are stored in an array, which is returned at the end. |
| receive | receive function handles incoming Ether transfers. |
| Function Name | Description (Business Logic) |
|---|---|
| updateInternalCaller | The updateInternalCaller function allows the owner to update the list of internal callers, emitting an event to log the changes. The updateWeth, updateNetworkIdAndRouterAddress, updatePortalAddress, updateGatewayAddress, and updateGasReceiverAddress functions enable the owner to update respective addresses and configurations, ensuring the contract can adapt to changes in the underlying infrastructure or requirements. |
| swapInWithMagpieSignature | The swapInWithMagpieSignature 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 LibRouter.getData function and then calls the swapIn function with the retrieved data and a boolean flag set to true, indicating that a Magpie signature is being used. The function returns the amount of tokens received from the swap. |
| swapInWithUserSignature | The swapInWithUserSignature function, on the other hand, is restricted to internal callers through the onlyInternalCaller modifier. This function also retrieves swap data using LibRouter.getData. However, it includes an additional check to ensure that the fromAssetAddress is not a native asset, reverting the transaction with an InvalidAddress error if this condition is met. The function then calls swapIn with the retrieved data and a boolean flag set to false, indicating that a user signature is being used. It returns the amount of tokens received from the swap. |
| verifySignature | The verifySignature function is designed to verify the signature for a swap operation by constructing a message from the provided SwapData 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 toAddress, fromAssetAddress, toAssetAddress, amountOutMin, gasFee, recipientNetworkId, recipientAddress, synthesisAddress, symbiosisAddress, bridgeFee, chainId, and clientId into the message. Additionally, it processes the destinationAddress and destinationChain by copying their lengths and values into memory and computing their keccak256 hashes. Finally, the function calls LibRouter.verifySignature 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. |
| swapIn | The swapIn 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 swapSequence to ensure each swap has a unique identifier. Using inline assembly, it retrieves the networkId and routerAddress from the stored networkIdAndRouterAddress variable. The function then verifies the signature of the swap data using the verifySignature function. If the swap data includes a permit, it calls LibRouter.permit to handle the permit process. It also transfers any associated fees using LibRouter.transferFees. Next, the function prepares the encoded deposit data and calculates its hash. It calls LibBridge.swapIn 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 bridgeIn 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 swapSequence with the incremented value. If they do not match, it reverts the transaction with a ReentrancyError. The function emits a BridgeIn event to log the details of the inbound swap operation. |
| bridgeIn | The bridgeIn 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 portalAddress 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, synthesis address, symbiosis address, refund address, chain ID, and client ID. If the execution of this call fails, the function reverts with a SynthesisFailed error. The function then calls dataIn to handle the transfer fee, deposit data hash, net amount (amount minus bridge fee), asset address, and refund address. Finally, it retrieves the crosschainId from the assembly block and emits a BridgeIn event to log the details of the inbound asset transfer. This ensures that the bridging process is securely executed and properly recorded. |
| dataIn | The dataIn 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 IAxelarGasService to pay the native gas fee for the contract call and IAxelarGateway 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 Deposit event to log the details of the inbound data transfer. |
| execute | The execute function handles the execution of cross-chain commands by validating the contract call through the IAxelarGateway. It takes parameters such as the command ID, source chain, source address, and payload. If the validation fails, the function reverts with a NotApprovedByGateway error. Upon successful validation, it calls the addDeposit function to process the payload. |
| addDeposit | The addDeposit 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 Deposit event to log the details of the validated deposit, ensuring the integrity and traceability of the cross-chain transaction. |
| swapOut | The swapOut 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 LibRouter.getData. The function calculates the deposit data hash and checks the deposit amount. If no deposit is found, it reverts with a DepositIsNotFound error. Otherwise, it resets the deposit amount to zero and calls LibBridge.swapOut to execute the swap, returning the amount received from the swap. |
| multicall | The multicall 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.functionDelegateCall. 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. |
| Function Name | Description (Business Logic) |
|---|---|
| getBalanceOf | The getBalanceOf function retrieves the balance of a specified asset for a target address. It uses inline assembly to handle both native assets (Ether) and other ERC-20 tokens. For native assets, it directly retrieves the balance using the balance opcode. For ERC-20 tokens, it constructs a call to the balanceOf function of the token contract, passing the target address as an argument. If the call fails, it reverts with the returned data. |
| transferFrom | The transferFrom function performs a safe transfer of a specified asset from one address to another. It uses inline assembly to prepare a call to the transferFrom function of the asset’s contract, passing the sender’s address, the recipient’s address, and the amount to be transferred. If the transfer operation fails, it reverts with a TransferFromFailed error. This function ensures that asset transfers are handled securely and correctly. |
| transfer | The transfer function facilitates the transfer of a specified amount of an asset to a recipient address. If the asset is native (Ether), it uses a low-level call to transfer the amount directly. If the transfer fails, it reverts with a TransferFailed error. For non-native assets, it constructs a call to the transfer function of the asset’s contract using inline assembly. If the transfer operation fails, it also reverts with a TransferFailed error. This function ensures that both native and non-native asset transfers are handled securely. |
| approve | The approve function allows a spender address to spend a specified amount of an asset on behalf of the owner. It constructs a call to the approve function of the asset’s contract using inline assembly. If the approval operation fails, it attempts to reset the allowance to zero and then re-approve the specified amount. If these attempts fail, it reverts with an ApprovalFailed error. This function ensures that the approval process is robust and handles potential issues with resetting allowances. |
| permit | The permit function allows for the approval of a spender to spend a specified amount of an asset on behalf of the owner, using a signature. This function is useful for ERC-20 tokens that support the permit function, enabling gasless approvals. It constructs a call to the permit function of the asset’s contract using inline assembly, passing the owner’s address, spender’s address, amount, deadline, and the signature components (v, r, s). If the permit operation fails, it reverts with a PermitFailed error. |
| isSuccessful | The isSuccessful function checks if a call to a target contract was successful. It takes the target address, a success flag, and the returned data as inputs. If the call was successful and the returned data is empty, it checks if the target address is a contract by verifying the code length. If the returned data is not empty, it loads the result from the data using inline assembly. This function ensures that the success of a call is accurately determined, handling both contract and non-contract addresses. |
| execute | The execute function performs a low-level call to a target contract, handling both native and non-native assets. It uses inline assembly to construct and execute the call, passing the necessary parameters such as the target address (self), the amount of native asset to send (currentNativeAmount), and pointers to the input and output data. The function includes an internal helper function, isSuccessfulCall, which determines if the call was successful by checking the return data size and the existence of code at the target address. If the call fails, it reverts with the returned data. This function ensures that low-level calls are executed safely and correctly, providing a robust mechanism for interacting with other contracts. |
| Function Name | Description (Business Logic) |
|---|---|
| decodeDepositDataHash | This function converts a deposit data hash from a bytes format to a bytes32 format. This conversion is essential for handling and verifying deposit data within the contract. |
| encodeDepositDataHash | This function converts a deposit data hash from a bytes32 format back to a bytes format. This is useful for encoding deposit data for storage or transmission. |
| getDepositDataHash | This function generates a unique hash for the deposit data by assembling various pieces of information from the SwapData struct and other parameters. It ensures the integrity and uniqueness of the deposit data, which is crucial for tracking and verifying deposits accurately. |
| fillEncodedDepositData | The fillEncodedDepositData function is designed to populate a given variable with encoded deposit data. It takes three parameters: encodedDepositData, which is the placeholder for the deposit data, networkId, which identifies the sender’s network, and swapSequence, which is the current swap sequence number. The function uses inline assembly to copy the deposit data into the specified variable and then appends the network ID, the address, and the swap sequence to the encoded data. |
| swap | The swap function executes a swap operation using a specified router and a given amount of native currency. It takes the router’s address and the native amount as parameters and returns the amount received from the swap operation and a success flag. The function uses inline assembly to prepare the input data for the swap, including the function selector for swapWithoutSignature, and then performs the call to the router. If the call is successful, it retrieves the output amount from the response. |
| swapIn | The swapIn function executes an inbound swap operation using the provided data and addresses. It takes several parameters: swapData, which contains the details of the swap; encodedDepositData, which holds the encoded deposit data; fromAddress, the address from which the swap originates; routerAddress, the address of the router contract for the swap; and weth, the address of the Wrapped Ether contract. The function returns the amount received as output from the swap operation. The function first checks if the toAddress in swapData matches the current contract address, reverting with an InvalidToAddress error if it does not. It then verifies if the fromAssetAddress is native and if the msg.value is less than the amountIn, reverting with an InvalidAmountIn error if true. Depending on the asset addresses involved, the function performs different operations. If the fromAssetAddress is native and the toAssetAddress is weth, it wraps the native amount into weth. If the fromAssetAddress is weth and the toAssetAddress is native, it transfers the weth from the fromAddress to the contract and unwraps it. If both asset addresses are the same, it simply transfers the amount from the fromAddress to the contract. For other cases, it handles the swap operation by transferring the fromAssetAddress from the fromAddress to the contract, approving the router to spend the amount, and then calling the swap function. If the swap is unsuccessful, it reverts with the returned data. Finally, the function emits a SwapIn event with details of the swap operation, including the fromAddress, toAddress, asset addresses, total amount, output amount, and the encoded deposit data. |
| swapOut | The swapOut function executes an outbound swap operation using the provided swap and deposit data. It takes several parameters: swapData, which contains the swap details; depositAmount, which is the bridged amount to be swapped; depositDataHash, a hash of the deposit data; routerAddress, the address of the router contract for the swap; and weth, the address of the Wrapped Ether contract. The function returns the amount received as output from the swap operation. The function first checks if the depositAmount matches the sum of amountIn and gasFee from swapData, reverting with an InvalidDepositAmount error if it does not. If there is a gas fee, it transfers this fee to the sender. For the main swap operation, the function handles different scenarios based on the asset addresses involved. If the fromAssetAddress is weth and the toAssetAddress is native, it unwraps the weth and transfers the native amount to the toAddress. If the fromAssetAddress is native and the toAssetAddress is weth, it wraps the native amount into weth and transfers it to the toAddress. If both asset addresses are the same, it simply transfers the amount to the toAddress. For other cases, it prepares for the swap by approving the router to spend the fromAssetAddress amount and then calls the swap function. If the swap is unsuccessful, it reverts to transferring the fromAssetAddress amount to the toAddress and sets the toAssetAddress to fromAssetAddress. Finally, the function emits a SwapOut event with details of the swap operation, including the sender, toAddress, asset addresses, total amount, output amount, and the deposit data hash. |
| Function Name | Description (Business Logic) |
|---|---|
| getData | The getData function in the LibRouter library is designed to prepare and return a SwapData struct from the calldata. It begins by calculating the deadline from the calldata and checks if the transaction has expired by comparing it with the current timestamp. If the transaction is expired, it reverts with an ExpiredTransaction error. The function then proceeds to populate the SwapData struct with various parameters extracted from the calldata, including toAddress, fromAssetAddress, toAssetAddress, deadline, amountOutMin, gasFee, and amountIn. It also determines if the transaction includes a permit by checking the v value from the calldata and sets the hasPermit flag accordingly. Depending on whether the permit is present, it further checks for the presence of an affiliate and populates the affiliateAddress and affiliateFee fields if applicable. The function uses inline assembly for efficient data manipulation and storage within the SwapData struct. |
| transferFees | The transferFees function is responsible for transferring the necessary fees for a swap operation from the user’s account. It first checks if the fromAssetAddress is a native asset, in which case it sets the gasFee to zero. If there is a gasFee greater than zero, it transfers this fee from the user’s address to the contract’s address. Additionally, if there is an affiliateFee, the function checks if the asset is native. If it is, the fee is transferred directly to the affiliate’s address. Otherwise, the fee is transferred from the user’s address to the affiliate’s address using the transferFrom method. |
| permit | The permit function grants permission for the user’s asset to be used in a swap operation. It extracts the v, r, and s values, as well as the deadline from the calldata using inline assembly. These values are then used to call the permit method on the fromAssetAddress, allowing the contract to spend the specified amount of the user’s asset. The amount includes the amountIn, gasFee, and affiliateFee, ensuring that all necessary fees are covered by the permission granted. |
| recoverSigner | The recoverSigner function is a private, pure function that recovers the signer’s address from a hashed message and its signature components (r, s, and v). This function ensures the uniqueness of the signature by addressing potential malleability issues as outlined in the Ethereum Yellow Paper. It first checks if the s value is within the valid range, reverting with an InvalidSignature error if it is not. It also verifies that the v value is either 27 or 28, reverting with an InvalidSignature error if it is not. The function then uses the ecrecover function to obtain the signer’s address from the hash and the signature components. If the recovered address is the zero address, it reverts with an InvalidSignature error, ensuring that only valid signatures are accepted. |
| getDomainSeparator | The getDomainSeparator function is a private view function that generates a domain separator for EIP-712 typed data hashing. It first retrieves the current chain ID using inline assembly. The function then returns the keccak256 hash of an encoded EIP-712 domain, which includes the name, version, chain ID, and the contract’s address. The domain separator is crucial for ensuring the integrity and uniqueness of the signed data, preventing replay attacks across different domains. |
| verifySignature | The verifySignature function verifies the signature for a swap operation. It takes several parameters, including the SwapData struct, a pointer to the message data in memory, the length of the message data, a flag indicating whether to use the caller’s address for verification, and a slot in the internal callers storage for verification. The function first generates a domain separator using the getDomainSeparator function. It then constructs the message hash by storing various fields from the SwapData struct in memory and computing the keccak256 hash of the message data. The domain separator and message hash are combined to create the final digest. Using inline assembly, the function extracts the r, s, and v components of the signature from the calldata. If the useCaller flag is set, it recovers the signer’s address from the digest and verifies it against the internal callers storage. If the verification fails, it reverts with an InvalidSignature error. If the useCaller flag is not set, it simply recovers the signer’s address from the digest and returns it. |
| swapInWithUserSignature | The swapInWithUserSignature function, restricted to internal callers, facilitates swaps using a user signature. |
| swapInWithMagpieSignature | The swapInWithMagpieSignature function allows for token swaps using a Magpie signature, and can only be executed when the contract is not paused. |
| Network | Explorer |
|---|---|
| Ethereum | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Polygon | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| BSC | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Avalanche | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Arbitrum | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Optimism | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Base | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Polygon zkEVM | 0xf5f3b8faf45023fd92c0c88fedf73fb0529fc1cd |
| Blast | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| zkSync | 0xc5b20203b6807e742853c96ce7dcfb1e7b201c0a |
| Manta | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Scroll | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Metis | 0xf702814d2e1290f3d5f3202565df46272e1b1b92 |
| Fantom | 0xf702814d2e1290f3d5f3202565df46272e1b1b92 |
| Taiko | 0xf5f3b8faf45023fd92c0c88fedf73fb0529fc1cd |
| Sonic | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Ink | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Linea | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Berachain | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Unichain | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Abstract | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Plasma | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| HyperEVM | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Monad | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Stable | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| MegaETH | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Morph | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| 0g | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Telos | 0xf5f3b8faf45023fd92c0c88fedf73fb0529fc1cd |
| Katana | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Tempo | 0x20f6ee51340adeed01a59b0e65cb3703f3dc860c |
| Pharos | 0xf702814d2e1290f3d5f3202565df46272e1b1b92 |
| Network | Address |
|---|---|
| Solana | 2DAtv2URAcb9ZHVMHEB8E3TFBTk9PoNSYknjq8DVr69c |
| Network | Explorer |
|---|---|
| Ethereum | 0xa6e941eab67569ca4522f70d343714ff51d571c4 |
| Polygon | 0xa6e941eab67569ca4522f70d343714ff51d571c4 |
| BSC | 0x29ed0a2f22a92ff84a7f196785ca6b0d21aeec62 |
| Avalanche | 0x3611b82c7b13e72b26eb0e9be0613bee7a45ac7c |
| Arbitrum | 0xfb1b08ba6ba284934d817ea3c9d18f592cc59a50 |
| Optimism | 0xa6e941eab67569ca4522f70d343714ff51d571c4 |
| Base | 0x5e766616aabfb588e23a8ea854e9dbd1042affd3 |
| Polygon zkEVM | 0x3950bf2fff93e5d502430f17924aef4c621ea772 |
| Blast | 0xc9f1a0ba8071685e3529982b59c8645b27734bd0 |
| zkSync | 0xb44958ff91b4b67d8d4db010e38ccffe52551ecb |
| Manta | 0x6d3c9920c7a2617ea98c9afcf7219d0f166ab758 |
| Scroll | 0x9ee06954418687c6fb3a9966f7c46e0a245f0183 |
| Metis | 0xda52965937213f51bfe716f338714afa80ff17bf |
| Fantom | 0x5affa5312ade198d9527acf058fee1c8ed8fe9f3 |
| Taiko | 0x5affa5312ade198d9527acf058fee1c8ed8fe9f3 |
| Sonic | 0xc325856e5585823aac0d1fd46c35c608d95e65a9 |
| Ink | 0x52bebb970697476313ae2b3383f40d4afd4ad9d3 |
| Linea | 0x52bebb970697476313ae2b3383f40d4afd4ad9d3 |
| Berachain | 0x52bebb970697476313ae2b3383f40d4afd4ad9d3 |
| Unichain | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Abstract | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Plasma | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| HyperEVM | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Monad | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Stable | 0x956Df8424B556F0076E8abf5481605f5A791cc7f |
| MegaETH | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Morph | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| 0g | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Telos | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Katana | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Tempo | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Pharos | 0x956df8424b556f0076e8abf5481605f5a791cc7f |
| Network | Explorer |
|---|---|
| Ethereum | 0x73731dacb1ee5906aa515512fcda2074d690487a |
| Polygon | 0x73731dacb1ee5906aa515512fcda2074d690487a |
| BSC | 0x73731dacb1ee5906aa515512fcda2074d690487a |
| Avalanche | 0x15392211222b46a0ea85a9a800830486d144848d |
| Arbitrum | 0xeb57de1f78304cf925405efc1089793aabddb0d5 |
| Optimism | 0x73731dacb1ee5906aa515512fcda2074d690487a |
| Base | 0x1b3bbce7241b357d8a8e3523f6d91ee50f37333a |
| Polygon zkEVM | - |
| Blast | - |
| zkSync | - |
| Manta | - |
| Scroll | 0x3ca605083506096fba34461b471db7ed03290b2d |
| Metis | 0x596384bdffc9f563b53791aeec50a42ff51c3e42 |
| Fantom | - |
| Taiko | - |
| Sonic | - |
| Ink | - |
| Linea | - |
| Berachain | - |
| Network | Explorer |
|---|---|
| Ethereum | 0x34cdce58cbdc6c54f2ac808a24561d0ab18ca8be |
| Polygon | 0x34cdce58cbdc6c54f2ac808a24561d0ab18ca8be |
| BSC | 0x34cdce58cbdc6c54f2ac808a24561d0ab18ca8be |
| Avalanche | 0x73731dacb1ee5906aa515512fcda2074d690487a |
| Arbitrum | 0x44f6c16720e9b3d7b6b188d65b6808e1e54057b9 |
| Optimism | 0x34cdce58cbdc6c54f2ac808a24561d0ab18ca8be |
| Base | 0x2b14763c27b9661182c2503f6c9c4d47ba747dd2 |
| Polygon zkEVM | 0x2bcff213edff099019172eb95c025cc385849cb0 |
| Blast | - |
| zkSync | 0x9a82d959bfbcb1677585f111eca12a53c369c1b3 |
| Manta | 0x6a1431bb23e08e3209dae3130b441863855fc14b |
| Scroll | 0x5affa5312ade198d9527acf058fee1c8ed8fe9f3 |
| Metis | - |
| Fantom | - |
| Taiko | - |
| Sonic | - |
| Ink | - |
| Linea | - |
| Berachain | - |
| Network | Explorer |
|---|---|
| Ethereum | 0xeb57de1f78304cf925405efc1089793aabddb0d5 |
| Polygon | 0xeb57de1f78304cf925405efc1089793aabddb0d5 |
| BSC | - |
| Avalanche | 0x34cdce58cbdc6c54f2ac808a24561d0ab18ca8be |
| Arbitrum | 0xd0daa14d983a40b4c91f7b6875faa8d27f024e73 |
| Optimism | 0xeb57de1f78304cf925405efc1089793aabddb0d5 |
| Base | 0x6c9b3a74ae4779da5ca999371ee8950e8db3407f |
| Polygon zkEVM | - |
| Blast | - |
| zkSync | - |
| Manta | - |
| Scroll | - |
| Metis | - |
| Fantom | - |
| Taiko | - |
| Sonic | - |
| Ink | - |
| Linea | - |
| Berachain | - |
{status}
}Architecture diagram - cross chain swap
| Benefit | Reasoning |
|---|---|
| Modularity | The diamond proxy pattern allows for greater modularity in software design. By encapsulating dependencies between objects within a proxy, you can modify or replace objects without affecting the rest of the system. This makes it easier to develop, test, and maintain complex systems. |
| Separation of Concerns | The diamond proxy pattern separates concerns between different objects in the system. Each object is responsible for a specific set of functionalities, and communication between objects is managed by the proxy. This makes it easier to understand and reason about the system. |
| Encapsulation | The diamond proxy pattern encapsulates dependencies and implementation details within the proxy object. This reduces coupling between objects and improves the overall design of the system. It also makes it easier to modify or replace objects without affecting the rest of the system. |
| Lazy initialization | With the diamond proxy pattern, objects are only created when they are actually needed. This reduces memory usage and improves the performance of the system. |
| Testing | The diamond proxy pattern makes it easier to test individual components of the system in isolation. You can test the behavior of each object separately and use mocks or stubs to simulate interactions between objects. |
| Field | Type | Description |
|---|---|---|
| input | bytes memory | A byte array containing necessary swapping parameters. |
| Field | Type | Description |
|---|---|---|
| | The amount received after swapping. |
| Field | Description |
|---|---|
| A default operation indicating no mathematical operation is to be performed or possibly used as a placeholder. |
| Represents addition, the operation of adding two numbers together to find their sum. |
| Represents subtraction, the operation of taking one number away from another to find the difference. |
| Represents multiplication, the operation of scaling one number by another to find the product. |
| Represents division, the operation of determining how many times one number is contained within another to find the quotient. |
| Stands for power, an operation that raises a number to the exponent of another number, essentially multiplying a number by itself a specified number of times. |
| Likely represents an operation to find the absolute value of a number within a 128-bit context, ensuring the result is positive or zero. |
| Similar to Abs128, this likely refers to finding the absolute value of a number within a 256-bit context, which allows for handling larger numbers. |
| Stands for "shift right", a bitwise operation that shifts all bits in a binary representation of a number to the right by a specified number of positions, effectively dividing the number by a power of two. |
| Stands for "shift left", a bitwise operation that shifts all bits in a binary representation of a number to the left by a specified number of positions, effectively multiplying the number by a power of two. |
| Field | Description |
|---|---|
| This action representa a generic call to a function within a contract. |
| Represents an approval operation. |
| Indicates a transfer-from operation. |
| Represents a direct transfer operation. |
| This action is used for wrapping tokens, such as converting Ether to Wrapped Ether (WETH). |
| The opposite of Wrap, this is used for unwrapping tokens, like converting WETH back to Ether. |
| to check the balance of an account or contract for a specific asset. |
| Represents an swap operation related to the Uniswap V2 protocol. |
| For swap operation specific to Uniswap V3. |
| Indicates swap operation related to Trader Joe V2.1. |
| Represents swap operation related to the Solidly protocol. |
| Indicates swap operation related to KyberSwap Classic |
| Indicates swap operation related to Ambient Protocol. |
| Field | Description |
|---|---|
| The amountIn in native tokens. |
| The function selector for the command. |
| The recipient address. |
| The amount in. |
| The data that contains information for the command to be performed. |
| The amount received after the previous swap. |
| The address of the protocol router used for swapping. |
| The address who requested the command to be performed. |
| Field | Type | Description |
|---|---|---|
| | This field uses the previously defined CommandAction enum to specify the type of action this command represents. |
| | The specific meaning of this value would depend on the context in which the CommandData struct is used. |
| | indicating the length of the input data for this command. |
| | specifies the starting position of a sequence of data related to this command. |
| | marks the end position of the sequence of data. |
| | the address of a contract or an account that is the target of this command. |
| Field | Type | Description |
|---|---|---|
| commandData | | |
| Field | Type | Description |
|---|---|---|
| lastAmountOut | uint256 | The amount received after the previous swap. |
| commandData | CommandData | |
| Field | Type | Description |
|---|---|---|
| commandData | CommandData | |
| nativeAmount | uint256 | The amountIn in native tokens. |
| selector | bytes4 | The function selector for the command. |
| input | bytes | The data that contains information for the command to be performed. |
| Field | Type | Description |
|---|---|---|
| | The different commands like approval, transfer, transferFrom etc. |
| Field | Type | Description |
|---|---|---|
| The function selector for each of the commands. |
| Field | Type | Description |
|---|---|---|
| | Identifier for each command. We have one selector / command. |
| Field | Type | Description |
|---|---|---|
| | The function selector for the specified command. |
| Field | Type | Description |
|---|---|---|
| commandAction | CommandAction | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An array containing identifiers for networks. |
| | An array containing chain identifiers corresponding to the networks in networkIds. |
| Field | Type | Description |
|---|---|---|
| | An array containing identifiers for networks. |
| | An array containing chain identifiers corresponding to the networks in networkIds. |
| Field | Type | Description |
|---|---|---|
| | A bytes array that represents the input payload. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The amount received after the bridgining |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An array containing identifiers for networks. |
| | An array containing chain identifiers corresponding to the networks in networkIds. |
| Field | Type | Description |
|---|---|---|
| | An array containing identifiers for networks. |
| | An array of bytes32 values representing Magpie Celer Bridge addresses. |
| Field | Type | Description |
|---|---|---|
| | An array of identifier defined by the magpie team for each network |
| | An array of magpieStargateBridge addresses for each network in the form of bytes32 |
| Field | Type | Description |
|---|---|---|
| | An array of identifier defined by the magpie team for each network |
| | An array of magpieStargateBridge addresses for each network in the form of bytes32 |
| Field | Type | Description |
|---|---|---|
| | The token sequence defined by magpie |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An instance of the BridgeType enum that specifies the type of the bridge. |
| | A bytes field that contains additional payload data for the bridge operation. |
| Field | Type | Description |
|---|---|---|
| | An unsigned 16-bit integer that represents the ID of the recipient network. |
| | An instance of the BridgeArgs struct that contains the bridge arguments. |
| | A uint256 value that represents the amount being bridged. |
| | An address that specifies the address of the asset on the recipient network. |
| | An instance of the TransferKey struct that represents a transfer key for the bridge operation. |
| Field | Type | Description |
|---|---|---|
| | An instance of the BridgeArgs struct that contains the bridge arguments. |
| | An instance of the Transaction struct that represents the transaction for the bridge-out operation. |
| | An instance of the TransferKey struct that represents a transfer key for the bridge operation. |
| Field | Type | Description |
|---|---|---|
| | An unsigned 16-bit integer that represents the ID of the recipient network. |
| | A uint256 value that represents the amount being refunded. |
| | An address that specifies the address of the asset on the recipient network. |
| | An instance of the TransferKey struct that represents a transfer key for the bridge operation. |
| | An instance of the BridgeArgs struct that contains the bridge arguments. |
| | The bytes that contain some message which are required while bridging. |
| Field | Type | Description |
|---|---|---|
| | This field is an unsigned 16-bit integer that represents the chain ID of the recipient on Layer 0. Layer 0 typically refers to the root blockchain or the main chain. |
| | This field is a uint256 value that represents the ID or identifier of the source pool. The exact meaning and context of the pool ID may depend on the specific implementation or protocol using this struct. |
| | This field is a uint256 value that represents the ID or identifier of the destination pool. Similarly to the source pool ID, the meaning and context of the destination pool ID depend on the specific implementation or protocol. |
| | This field is a uint256 value that represents the fee associated with the bridge operation. |
| | The amount of gas fees one needs to execute the transaction. |
| Field | Type | Description |
|---|---|---|
| | This field is of type bytes and represents the source address. |
| | This field is of type uint256 and represents a nonce value. Nonce is commonly used as a security measure to prevent replay attacks or ensure transaction ordering. |
| | This field is of type uint16 and represents the source chain ID. It identifies the chain from which the bridge-out operation originates. |
| Field | Type | Description |
|---|---|---|
| | This field is of type address and represents the address of the router |
| | This field is of type uint256 and represents the amount being bridged in. It specifies the quantity of tokens or assets involved in the bridge-in operation. |
| | This field is of type bytes and represents the recipient address. The encoding and interpretation of the recipient address may depend on the specific requirements or format of the bridge system or protocol. |
| | |
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | Payload consisting of data necessary for bridging out |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | Payload consisting of data necessary for bridging in. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The amount that needs to be swapped |
| | |
| Field | Type | Description |
|---|---|---|
| | The minimum amount out |
| Field | Type | Description |
|---|---|---|
| | The recipient address in bytes32 |
| Field | Type | Description |
|---|---|---|
| | The receipient address in bytes |
| Field | Type | Description |
|---|---|---|
| | The address that initiated the transaction. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The network identifier of the destination chain |
| | |
| | The amount that needs to be swapped |
| | The final token that needs to be received |
| Field | Type | Description |
|---|---|---|
| | The sequence received after a successful bridging in |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | Payload consisting of data necessary for briding out. |
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | The amount received after bridging out. |
| Field | Type | Description |
|---|---|---|
| | An array of unsigned 16-bit integers (uint16) representing network identifiers. |
| | An array of |
| Field | Type | Description |
|---|---|---|
| | An array of unsigned 16-bit integers (uint16) representing network identifiers. |
| | An array of bytes32 values representing Magpie Stargate Bridge addresses. |
| Field | Type | Description |
|---|---|---|
| | the receipient chain id as per wormhole standard. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | decimals of the source asset |
| | decimals of the target asset |
| | amount that needs to be normalized |
| Field | Type | Description |
|---|---|---|
| | the normalized amount |
| Field | Type | Description |
|---|---|---|
| | decimal of the source asset |
| | decimal of the target asset |
| | amount that needs to be denormalized |
| Field | Type | Description |
|---|---|---|
| | the denormalized amount |
| Field | Type | Description |
|---|---|---|
| | Payload necessary for bridging in. |
| Field | Type | Description |
|---|---|---|
| | The receipient chain id fetched from the payload |
| Field | Type | Description |
|---|---|---|
| | The network identifier of the destination chain |
| | |
| | The amount that needs to be swapped |
| | The final token that needs to be received |
| Field | Type | Description |
|---|---|---|
| | The sequence received after a successful bridging in |
| Field | Type | Description |
|---|---|---|
| | Payload contains data that is necessary for bridging out |
| | |
| Field | Type | Description |
|---|---|---|
|
| The amount received after bridging out |
| Field | Type | Description |
|---|---|---|
| |
Each named value is assigned an implicit integer value, starting at 0 for the first value and incrementing by 1 for each subsequent value. In this case, |
| |
Each named value is assigned an implicit integer value, starting at 0 for the first value and incrementing by 1 for each subsequent value. In this case, |
| | the network id of the recipient chain. |
| | the address of the source asset address that will get swapped. Example: 0x0000000000000000000000007b155e039f60ad89b3b3761a513238dfeebd8ab1 |
| | the address of the destination asset address that will be received after swapping. Example: 0x0000000000000000000000003b981e413aedcd075d96a8f28d2aaff9b15f4f01 |
| | the address of the recipient. Example: 0x000000000000000000000000EE2249f8E5c4E84882eBA16DC991F3Fd4404C955 |
| | the address of the aggregator at the destionation address. |
| | the minimum swapped amount that is acceptable by the user. Example: 100000000000000000 |
| | the gas fee that the user can pay for the swapping. Example: 100000 |
| | the sequence we receive while transferring the tokens over the bridge. |
struct TransactionValidation {
bytes32 fromAssetAddress;
bytes32 toAssetAddress;
bytes32 toAddress;
uint256 amountOutMin;
uint256 swapOutGasFee;
}
| Field | Type | Description |
|---|---|---|
| | This field is of type bytes32 and represents the address of the asset being transferred from. The address is typically encoded as a 32-byte value. |
| | This field is of type bytes32 and represents the address of the asset being transferred to. Similar to fromAssetAddress, it is encoded as a 32-byte value. |
| | This field is of type bytes32 and represents the destination address of the transfer. It is also encoded as a 32-byte value. |
| | This field is of type uint256 and represents the minimum amount of the transferred asset that should be received. It defines a threshold for the expected output amount. |
| | This field is of type uint256 and represents the gas fee associated with the swap or transfer operation. It specifies the amount of gas required for completing the transaction. |
| Field | Type | Description |
|---|---|---|
| | the transaction struct to perform the encoding. |
| Field | Type | Description |
|---|---|---|
| | returns the encoded data in the form of bytes. |
| Field | Type | Description |
|---|---|---|
| | the payload in bytes that needs to be decoded |
| Field | Type | Description |
|---|---|---|
| | returns the Transaction struct after the decoding is completed. |
| Field | Type | Description |
|---|---|---|
| | network identifier of the target chain |
| | |
| | the amount that needs to be swapped |
| | the target asset |
| Field | Type | Description |
|---|---|---|
| | the sequence received after a successful bridgIn |
| Field | Type | Description |
|---|---|---|
| | |
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | The amount received after bridging out. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An array of network identifier for each blockchain. These are defined by the magpie team. |
| | An array of blockchain identifiers |
| Field | Type | Description |
|---|---|---|
| | An array of blockchain identifiers |
| | An array of network identifier for each blockchain. These are defined by the layerzero team. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An array of blockchain identifiers |
| | An array of network identifier for each blockchain. These are defined by the wormhole team. |
| Field | Type | Description |
|---|---|---|
| | The sequence provide by magpie team for the data transfer |
| Field | Type | Description |
|---|---|---|
| | The chain id of the source chain |
| | The address which will receive the data |
| | random or pseudo-random number that is used only once. |
| | Payload + extra information like which data transfer type has been used |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | This field is of type uint16 and represents the network ID of the data transfer protocol. |
| | This field is of type DataTransferType (an enum) and represents the type of data transfer, either Wormhole or LayerZero. |
| | This field is of type bytes and represents the payload of the data transfer. |
| Field | Type | Description |
|---|---|---|
| | This field is of type DataTransferInProtocol and represents the data transfer protocol details, including the network ID, data transfer type, and payload. |
| | This field is of type TransferKey and represents a transfer key associated with the data transfer. |
| | This field is of type bytes and represents the payload of the data transfer. |
| Field | Type | Description |
|---|---|---|
| | This field is of type DataTransferType (an enum) and represents the type of data transfer, either Wormhole or LayerZero. |
| | This field is of type bytes and represents the payload of the data transfer. |
| Field | Type | Description |
|---|---|---|
| | Payload + extra information like which data transfer type has been used |
| Field | Type | Description |
|---|---|---|
| payload | | the original payload |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| | The data necessary for swapping. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An array of wormhole chain identifiers |
| | An array of network identifiers provided by magpie team. |
| Field | Type | Description |
|---|---|---|
| | Payload that contains the data which will be transferred over the blockchains |
| Field | Type | Description |
|---|---|---|
| | payload required for receiving the data |
| Field | Type | Description |
|---|---|---|
| | Payload + extra information like which data transfer type has been used |
| Field | Type | Description |
|---|---|---|
| | The core sequence provided by magpie for data transfer |
| Field | Type | Description |
|---|---|---|
| | The sequence received by the wormhole core bridge. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | An array of network identifiers provided by magpie team. |
| | An array of layer zero blockchain identifiers |
| Field | Type | Description |
|---|---|---|
| | An array of layer zero blockchain identifiers |
| | An array of network identifiers provided by magpie team. |
| Field | Type | Description |
|---|---|---|
| | Payload required for transfering data from one chain to another |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | target address |
| | source address |
| Field | Type | Description |
|---|---|---|
| | concatenated target and source address |
| Field | Type | Description |
|---|---|---|
| | Payload necessary for data transfer |
| | |
| Field | Type | Description |
|---|---|---|
| | Payload necessary for data transfer |
| Field | Type | Description |
|---|---|---|
| | Payload + extra information like which data transfer type has been used |
| Field | Type | Description |
|---|---|---|
| | |
| | Payload + extra information like which data transfer type has been used |
| Field | Type | Description |
|---|---|---|
| | The layer zero chain identifier for the source chain |
| | The address that will receive the data from layerzero |
| | Payload + extra information like which data transfer type has been used |
| Field | Type | Description |
|---|---|---|
| | Address of wrapped native address (WETH for Ethereum, WMATIC for Polygon etc.) |
| Field | Type | Description |
|---|---|---|
| | This new address is the updated address for the Magpie Router within the contract. |
| Field | Type | Description |
|---|---|---|
| | networkId of the current chain in Magpie protocol, it is different from the actual networkId ethereum: 1 polygon: 2 bsc: 3 avalanche: 4 arbitrum: 5 optimism: 6 |
| Field | Type | Description |
|---|---|---|
| | networkIds of the networks we want to add |
| | Address of MagpieAggregator contracts on the specified chains/networks |
| Field | Type | Description |
|---|---|---|
| | SwapInArgs is a struct, its explained here |
| Field | Type | Description |
|---|---|---|
| | amountOut that you will receive after swapping tokens |
| Field | Type | Description |
|---|---|---|
| | SwapOutArgs is a struct, its explained here |
| Field | Type | Description |
|---|---|---|
| | amountOut that you will receive after swapping tokens |
| Field | Type | Description |
|---|---|---|
| | Address of the token for which you want to query deposit |
| Field | Type | Description |
|---|---|---|
| It returns the amount of deposited assets |
| Field | Type | Description |
|---|---|---|
| | Address of the token which will be withdrawn |
| Field | Type | Description |
|---|---|---|
| | the address of the asset whose deposited amount needs to be retrieved |
| | the address of the user who has deposited the asset |
| Field | Type | Description |
|---|---|---|
| amount | | the deposited amount |
| Field | Type | Description |
|---|---|---|
| | the source network identifier provided by the magpie team for each bloackchain |
| | the address of the user |
| | the sequence stored in our data base |
| Field | Type | Description |
|---|---|---|
| True if the key has been used false if not |
| Field | Type | Description |
|---|---|---|
| bytes memory | |
| | |
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | |
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | The address of the asset being swapped out. |
| | The address of the asset to which the swap is being performed. |
| | The address to which the swapped asset will be transferred. |
| | The address to which any transaction fee associated with the swap will be sent. |
| | The amount of the asset being swapped out. |
| | The amount of the asset being swapped out. |
| Field | Type | Description |
|---|---|---|
| | Address of the Wrapped Ether (WETH) contract. |
| Field | Type | Description |
|---|---|---|
| | The address of the magpie router. |
| Field | Type | Description |
|---|---|---|
| | The network ID associated with the application. |
| Field | Type | Description |
|---|---|---|
| | The network ID associated with the application. |
| | The Magpie Diamond contract addresses for each of the networkIDs |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The amount received after swapping |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The amount received after swapping |
| Field | Type | Description |
|---|---|---|
| | Address of the asset that will be deposited |
| Field | Type | Description |
|---|---|---|
| | The deposited amount |
| Field | Type | Description |
|---|---|---|
| | The asset that will be withdrawn |
| Field | Type | Description |
|---|---|---|
| | Address of the asset that will be deposited |
| | Address of the user who has deposited the asset |
| Field | Type | Description |
|---|---|---|
| | Deposited amount |
| Field | Type | Description |
|---|---|---|
| | networkId of the current chain in Magpie protocol, it is different from the actual networkId ethereum: 1 polygon: 2 bsc: 3 avalanche: 4 arbitrum: 5 optimism: 6 |
| | The address who initiated the transfer. |
| | The magpie sequence for the current swap. |
| Field | Type | Description |
|---|---|---|
| | Flag used to identify if the transfer key has been used for swapping or not. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| transferKey | | |
| payload | | A string of bytes that contains transactional data. |
| Field | Type | Description |
|---|---|---|
| | an array of function selectors |
| | an array of data that needs to be fed into the selectors |
| Field | Type | Description |
|---|---|---|
| | an array of function selectors |
| | an array of data that needs to be fed into the selectors |
| Field | Type | Description |
|---|---|---|
| | The asset that will be checked for a native token. |
| Field | Type | Description |
|---|---|---|
| | Flag to identify if the asset is native or not. |
| Field | Type | Description |
|---|---|---|
| | Asset whose balance needs to be found |
| Field | Type | Description |
|---|---|---|
| | Balance of the asset |
| Field | Type | Description |
|---|---|---|
| | Asset whose balance needs to be found. |
| | The address where the balance is checked from. |
| Field | Type | Description |
|---|---|---|
| Balance of the specific asset. |
| Field | Type | Description |
|---|---|---|
| | Asset that will be transferred |
| | address that will send the asset |
| | address that will receive the transferred asset |
| | amount of an asset that will be transferred |
| Field | Type | Description |
|---|---|---|
| | Asset that will be transferred |
| | address that will receive the transferred asset |
| | amount of an asset that will be transferred |
| Field | Type | Description |
|---|---|---|
| | The asset that will be approved. |
| | Address of a contract that will use the owners asset. |
| | Asset amount that can be spent. |
| Field | Type | Description |
|---|---|---|
| | Address of the asset that will be deposited |
| | Address of the Wrapped Ether (WETH) contract. |
| | Depositing amount |
| Field | Type | Description |
|---|---|---|
| | The asset whose allowance will be granted to the spender. |
| | Address of the owner who owns the asset. |
| | Address of a contract that will use the owners allowance. |
| Field | Type | Description |
|---|---|---|
| | The allowed amount |
| Field | Type | Description |
|---|---|---|
| | The asset that will be withdrawn |
| | Address of the Wrapped Ether (WETH) contract. |
| | Address that will receive withdrawn token. |
| | Amount that needs to be withdrawn |
| Field | Type | Description |
|---|---|---|
| | The asset address whose decimals we are finding. |
| Field | Type | Description |
|---|---|---|
| | The decimals of the asset address |
| Field | Type | Description |
|---|---|---|
| | Address of the target contract. |
| | To check if the call to the contract was successful or not. |
| | The data was sent while calling the target contract. |
| Field | Type | Description |
|---|---|---|
| | The success of the call. |
| Field | Type | Description |
|---|---|---|
| | The address of the contract to which the call is being made. |
| | The parameters or data to be sent in the call. |
| Field | Type | Description |
|---|---|---|
| | The success of the call. |
| Field | Type | Description |
|---|---|---|
| | The bytes that contains the address. |
| | The starting position to retrieve the address from the bytes. |
| Field | Type | Description |
|---|---|---|
| | The retrieved address from the bytes. |
| Field | Type | Description |
|---|---|---|
| | The string of bytes that needs to be sliced |
| | The starting position to begin slicing |
| | The length of the byte |
| Field | Type | Description |
|---|---|---|
| | The sliced byte |
| Field | Type | Description |
|---|---|---|
| | The bytes that needs to be concatenated. |
| | The bytes that needs to be concatenated. |
| Field | Type | Description |
|---|---|---|
| | The concatenated bytes |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | Address of the main registry of the curve protocol. |
| | Address of the crypto registry of the curve protocol |
| | Address of the crypto factory of the crypto factory |
| Field | Type | Description |
|---|---|---|
| | The protocol identifier provided by magpie team. |
| | The function selector of the AMM. |
| | The address of the facet of the AMM. |
| Field | Type | Description |
|---|---|---|
| | The wormhole token bridge address |
| Field | Type | Description |
|---|---|---|
| | The stargate router address. |
| Field | Type | Description |
|---|---|---|
| | The wormhole core bridge address. |
| | The level of finality the guardians will reach before signing the message |
| Field | Type | Description |
|---|---|---|
| | The router address of layer zero protocol |
| Field | Type | Description |
|---|---|---|
| | The message bus address of celer bridge |
| Field | Type | Description |
|---|---|---|
| | Address of the Wrapped Ether (WETH) contract. |
| | The network ID associated with the application. |
| | A mapping of network IDs to Magpie aggregator addresses. |
| | Tracks the total deposits made by each user. |
| | Tracks the deposits made by each user for specific token addresses. |
| | Tracks the usage status of transfer keys for specific network IDs, sender addresses, and swap sequences. |
| | A counter used for generating swap sequences. |
| | A flag indicating whether the contract is paused or not. |
| | A flag indicating whether reentrancy guard is enabled or not. |
| | A mapping of network IDs to AMMs. |
| | Contains settings related to Curve AMMs. |
| | A mapping used for storing data transfer payloads. |
| | Contains settings related to the Stargate bridge. |
| | A mapping of network IDs to Magpie Stargate bridge addresses. |
| | Contains settings related to the Wormhole Token bridge. |
| | Tracks the token sequences for the Wormhole bridge. |
| | Contains settings related to Wormhole data transfers. |
| | A mapping of network IDs for the Wormhole bridge. |
| | Tracks the core sequences for the Wormhole bridge. |
| | Contains settings related to LayerZero data transfers. |
| | A mapping of chain IDs for LayerZero data transfers. |
| | A mapping of network IDs for LayerZero data transfers. |
| | Address of the Magpie Router |
| | A mapping to show how much amount has been deposited why which address along with the message passed by the address and the networkId |
| | used to associate a boolean value (bool) with a single byte integer (uint8). |
| | |
| | A mapping of chain IDs for celer bridge transfers. |
| | A mapping of network Ids, data, chain Id, and address to the amount being deposited. |
| | A mapping of network Ids, data, and chain id to the refund address. |
| | A mapping of network ID to the magpie celer bridge address in the form of bytes. |
| | |
| | A mapping of network ID to the magpie stargate bridge V2 address in the form of bytes. |
| Field | Type | Description |
|---|---|---|
| | AppStorage struct. |
| Field | Type | Description |
|---|---|---|
| | Address for the main Curve registry. |
| | Address for the crypto Curve registry. |
| | Address for the crypto Curve factory. |
| Field | Type | Description |
|---|---|---|
| | An identifier for the AMM protocol. |
| | A function selector. |
| | The address where this AMM resides. |
| Field | Type | Description |
|---|---|---|
| | The address of the Wrapped Ether contract. |
| | Address of the Magpie Aggregator contract. |
| | A mapping of different AMMs, indexed by a uint16 value. |
| | |
| Field | Type | Description |
|---|---|---|
| | Mapping of command to its corresponding function selector. |
| Field | Type | Description |
|---|---|---|
| | networkId of the current chain in Magpie protocol, it is different from the actual networkId ethereum: 1 polygon: 2 bsc: 3 avalanche: 4 arbitrum: 5 optimism: 6 |
| | The address who initiated the transfer. |
| | The magpie sequence for the current swap. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The transferKey concatenated and converted to bytes |
| Field | Type | Description |
|---|---|---|
| | The data which contains the transferKey. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | An array of amounts whose sum needs to be found out. |
| Field | Type | Description |
|---|---|---|
| | The final sum of all the amounts |
| Field | Type | Description |
|---|---|---|
| | This is a 16-bit unsigned integer representing the offset for the amounts section in the transaction calldata. Offsets are used to locate specific data within a block of calldata. |
| | Similar to amountsOffset, this is a 16-bit unsigned integer representing the offset for another data section in the calldata. The specific nature of this data depends on the context in which SwapData is used. |
| | This is a 16-bit unsigned integer indicating the starting point of the commands section in the calldata. Commands in the context of a swap refers to specific actions. |
| | This is a 16-bit unsigned integer marking the end of the commands section in the calldata. Knowing the start and end of the commands section helps in parsing and executing them correctly. |
| | Represents the length of all of the commands. |
| | A 256-bit unsigned integer representing the amount of the asset being provided in the swap. |
| | This is the Ethereum address to which the output of the swap (the swapped asset) will be sent. |
| | The Ethereum address of the asset being swapped from. This could be the contract address of an ERC-20 token or another type of asset. |
| | The Ethereum address of the asset being swapped to. Like fromAssetAddress, this is typically the contract address of the target ERC-20 token or other asset types. |
| | A timestamp (usually in seconds since the Unix epoch) indicating the deadline by which the swap must be completed. |
| | The minimum amount of the output asset that must be received for the swap to be considered successful. |
| Field | Type | Description |
|---|---|---|
| swapData | SwapData memory | |
| Field | Type | Description |
|---|---|---|
| | |
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The withdrawal amount |
| Field | Type | Description |
|---|---|---|
| ||
| | |
| | |
| ||
| | |
|
| Field | Type | Description |
|---|---|---|
| |
| Field | Type | Description |
|---|---|---|
| | |
| | |
| | |
|
| Field | Type | Description |
|---|---|---|
| |
| Field | Type | Description |
|---|---|---|
| | Magpie Aggregator Address |
| | Stargate Router Address |
| Field | Type | Description |
|---|---|---|
| | A uint16 value representing the source chain ID from which the withdrawal is initiated. |
| | A uint256 value representing a unique identifier for the withdrawal transaction. |
| | An address representing the asset address that is being withdrawn. |
| | A bytes array representing the source address on the source chain. |
| | An instance of the TransferKey struct from the LibTransferKey library, which contains the network ID, sender address, and swap sequence associated with the withdrawal. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The amount that is withdrawn. |
| Field | Type | Description |
|---|---|---|
| | Network Id extracted from the TransferKey struct |
| | Sender Address extracted from the TransferKey struct |
| | Swap Sequence extracted from the TransferKey struct |
| | An address parameter representing the address of the received asset. |
| | A uint256 parameter representing the amount of the received asset. |
| | A bytes calldata parameter containing encoded information about the transfer, including the TransferKey. |
| Field | Type | Description |
|---|---|---|
| | Magpie Aggregator Address |
| | Stargate Router Address |
| Field | Type | Description |
|---|---|---|
| | A uint16 value representing the source chain ID from which the withdrawal is initiated. |
| | A uint256 value representing a unique identifier for the withdrawal transaction. |
| | An address representing the asset address that is being withdrawn. |
| | A bytes array representing the source address on the source chain. |
| | An instance of the TransferKey struct from the LibTransferKey library, which contains the network ID, sender address, and swap sequence associated with the withdrawal. |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | |
| Field | Type | Description |
|---|---|---|
| | The amount that is withdrawn. |
| Field | Type | Description |
|---|---|---|
| | Network Id extracted from the TransferKey struct |
| | Sender Address extracted from the TransferKey struct |
| | Swap Sequence extracted from the TransferKey struct |
| | An address parameter representing the address of the received asset. |
| | A uint256 parameter representing the amount of the received asset. |
| | A bytes calldata parameter containing encoded information about the transfer, including the TransferKey. |
| Network | Explorer |
|---|---|
| Ethereum | Explorer Link |
| Polygon | Explorer Link |
| BSC | Explorer Link |
| Avalanche | Explorer Link |
| Arbitrum-One | Explorer Link |
| Optimism | Explorer Link |
| Base | Explorer Link |
| Polygon zkEVM | Explorer Link |
| Blast | Explorer Link |
| zkSync | Explorer Link |
| Manta | Explorer Link |
| Scroll | Explorer Link |
| Metis | Explorer Link |
| Fantom | Explorer Link |
| Taiko | Explorer Link |
Sonic
Ethereum
Ink
Berachain
BNB Smart Chain
Base
Polygon
Optimism
Arbitrum
Avalanche
Manta
Polygon zkEVM
zkSync
Blast
Scroll
Linea
Metis
Fantom
As this is an on-chain swap, select the Sonic network and the STS token.