# Across Takers based on [Across protocol](https://docs.across.to/introduction/what-is-across). Two primary flows are supported: * *fill* - take pool asset for filling an already deposited order on another chain in exchange for repayment to the origin's pool of the same enclave * *deposit* - take pool asset and immediately deposit it expecting the order to be filled on another chain with the same enclave's pool as recipient ### Across Fill `AcrossFillTaker` implementation of taker provides an ability to take pool asset for filling an already deposited order on another chain in exchange for repayment to the origin's pool of the same enclave. The taker contract expects input and output tokens to *match* tokens managed by pools in corresponding chains. First, Across *deposit* must be committed on the origin chain. This action emits `FundsDeposited` event, the proof of which is expected on the take chain (`depositProof`). Along with the proof, the `takeToFillRelay` function accepts a number of parameters to reconstruct the original event for verification. > Number of `assets` for `take` is allowed to be different from `outputAssets` due to rebalance logic and strict validation of the original event components. The take sufficiency will be validated still and any surplus assets of the operation will be returned to the taker caller. Once event and parameters are verified, `SpokePool`'s `fillRelay` function is called. The taker contract provides the asset for the fill as `msg.sender`, specifying the *repayment* chain to be the origin `giveChain` chain and the *receiver* account to be `givePool`, thus ensuring `givePoolAsset` token will be returned to the enclave eventually. > If any of `take`, verification, or `fillRelay` phases fails, entire `takeToFillRelay` call fails. ### **Across Deposit** `AcrossDepositTaker` implementation of taker provides an ability to take pool asset and immediately deposit it expecting the order to be filled on another chain with the same enclave's pool as recipient. The order created has input and output tokens *matching* the tokens managed by the pools in corresponding chains. As the first step, a solver should call `takeToDeposit` function of the taker. The taker will receive at least `assets` from the pool, which is with the optional surplus should be sufficient to cover `inputAmount` (the rest is returned to the caller). The `outputAmount` value should cover pool-requested `minGiveAssets`. Once deposit is successfully created, the solver should obtain `FundsDeposited` event details and fill the order on the target chain (`giveChain`) using `SpokePool`'s `fillRelay` function. If this part is failed (deadline exceeded), funds are returned to the pool on the origin chain by Across protocol - as specified in the on-chain formed order. --- # 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.swaps.io/flex-liquidity-pools/takers/across.md?ask= ``` 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.