# LibRouter

The LibRouter smart contract facilitates efficient and secure swap operations by preparing and managing swap data, transferring necessary fees, and verifying permissions and signatures. The getData function extracts and organizes swap parameters from calldata, ensuring transactions are valid and not expired. The transferFees function handles the transfer of gas and affiliate fees, accommodating both native and non-native assets. The permit function grants the contract permission to use the user’s assets for the swap, covering all associated fees. The recoverSigner function ensures the integrity of signatures by recovering the signer’s address and validating it. Additionally, the getDomainSeparator function generates a domain separator for EIP-712 typed data hashing, crucial for preventing replay attacks. The verifySignature function verifies the signature for a swap operation by constructing a message hash and recovering the signer’s address, ensuring the authenticity of the transaction. Overall, the contract ensures secure and efficient swap operations through meticulous data handling and verification processes.

<table data-full-width="false"><thead><tr><th width="222">Function Name</th><th>Description (Business Logic)</th></tr></thead><tbody><tr><td><mark style="color:red;"><strong>getData</strong></mark> </td><td>The <mark style="color:red;"><strong>getData</strong></mark> function in the <mark style="color:red;"><strong>LibRouter</strong></mark> library is designed to prepare and return a <mark style="color:red;"><strong>SwapData</strong></mark> struct from the calldata. It begins by calculating the <mark style="color:red;"><strong>deadline</strong></mark> 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 <mark style="color:red;"><strong>ExpiredTransaction</strong></mark> error. The function then proceeds to populate the <mark style="color:red;"><strong>SwapData</strong></mark> struct with various parameters extracted from the calldata, including <mark style="color:red;"><strong>toAddress</strong></mark>, <mark style="color:red;"><strong>fromAssetAddress</strong></mark>, <mark style="color:red;"><strong>toAssetAddress</strong></mark>, <mark style="color:red;"><strong>deadline</strong></mark>, <mark style="color:red;"><strong>amountOutMin</strong></mark>, <mark style="color:red;"><strong>gasFee</strong></mark>, and <mark style="color:red;"><strong>amountIn</strong></mark>. It also determines if the transaction includes a permit by checking the <mark style="color:red;"><strong>v</strong></mark> value from the calldata and sets the <mark style="color:red;"><strong>hasPermit</strong></mark> flag accordingly. Depending on whether the permit is present, it further checks for the presence of an affiliate and populates the <mark style="color:red;"><strong>affiliateAddress</strong></mark> and <mark style="color:red;"><strong>affiliateFee</strong></mark> fields if applicable. The function uses inline assembly for efficient data manipulation and storage within the <mark style="color:red;"><strong>SwapData</strong></mark> struct.</td></tr><tr><td><mark style="color:red;"><strong>transferFees</strong></mark> </td><td>The <mark style="color:red;"><strong>transferFees</strong></mark> function is responsible for transferring the necessary fees for a swap operation from the user’s account. It first checks if the <mark style="color:red;"><strong>fromAssetAddress</strong></mark> is a native asset, in which case it sets the <mark style="color:red;"><strong>gasFee</strong></mark> to zero. If there is a <mark style="color:red;"><strong>gasFee</strong></mark> greater than zero, it transfers this fee from the user’s address to the contract’s address. Additionally, if there is an <mark style="color:red;"><strong>affiliateFee</strong></mark>, 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 <mark style="color:red;"><strong>transferFrom</strong></mark> method.</td></tr><tr><td><mark style="color:red;"><strong>permit</strong></mark> </td><td>The <mark style="color:red;"><strong>permit</strong></mark> function grants permission for the user’s asset to be used in a swap operation. It extracts the <mark style="color:red;"><strong>v</strong></mark>, <mark style="color:red;"><strong>r</strong></mark>, and <mark style="color:red;"><strong>s</strong></mark> values, as well as the <mark style="color:red;"><strong>deadline</strong></mark> from the calldata using inline assembly. These values are then used to call the permit method on the <mark style="color:red;"><strong>fromAssetAddress</strong></mark>, allowing the contract to spend the specified amount of the user’s asset. The amount includes the <mark style="color:red;"><strong>amountIn</strong></mark>, <mark style="color:red;"><strong>gasFee</strong></mark>, and <mark style="color:red;"><strong>affiliateFee</strong></mark>, ensuring that all necessary fees are covered by the permission granted.</td></tr><tr><td><mark style="color:red;"><strong>recoverSigner</strong></mark> </td><td>The <mark style="color:red;"><strong>recoverSigner</strong></mark> function is a private, pure function that recovers the signer’s address from a hashed message and its signature components (<mark style="color:red;"><strong>r</strong></mark>, <mark style="color:red;"><strong>s</strong></mark>, and <mark style="color:red;"><strong>v</strong></mark>). 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 <mark style="color:red;"><strong>s</strong></mark> value is within the valid range, reverting with an <mark style="color:red;"><strong>InvalidSignature</strong></mark> error if it is not. It also verifies that the v value is either 27 or 28, reverting with an <mark style="color:red;"><strong>InvalidSignature</strong></mark> error if it is not. The function then uses the <mark style="color:red;"><strong>ecrecover</strong></mark> 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 <mark style="color:red;"><strong>InvalidSignature</strong></mark> error, ensuring that only valid signatures are accepted.</td></tr><tr><td><mark style="color:red;"><strong>getDomainSeparator</strong></mark></td><td>The <mark style="color:red;"><strong>getDomainSeparator</strong></mark> 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.</td></tr><tr><td><mark style="color:red;"><strong>verifySignature</strong></mark> </td><td>The <mark style="color:red;"><strong>verifySignature</strong></mark> function verifies the signature for a swap operation. It takes several parameters, including the <mark style="color:red;"><strong>SwapData</strong></mark> 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 <mark style="color:red;"><strong>getDomainSeparator</strong></mark> function. It then constructs the message hash by storing various fields from the <mark style="color:red;"><strong>SwapData</strong></mark> 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 <mark style="color:red;"><strong>calldata</strong></mark>. If the <mark style="color:red;"><strong>useCaller</strong></mark> 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 <mark style="color:red;"><strong>InvalidSignature</strong></mark> error. If the <mark style="color:red;"><strong>useCaller</strong></mark> flag is not set, it simply recovers the signer’s address from the digest and returns it.</td></tr><tr><td><mark style="color:red;"><strong>swapInWithUserSignature</strong></mark></td><td>The <mark style="color:red;">swapInWithUserSignature</mark> function, restricted to internal callers, facilitates swaps using a user signature.</td></tr><tr><td><mark style="color:red;"><strong>swapInWithMagpieSignature</strong></mark> </td><td>The <mark style="color:red;"><strong>swapInWithMagpieSignature</strong></mark> function allows for token swaps using a Magpie signature, and can only be executed when the contract is not paused.</td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.fly.trade/developers/fly.trade-contracts/librouter.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.