> For the complete documentation index, see [llms.txt](https://docs.swaps.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.swaps.io/flex-liquidity-pools/takers/across.md).

# 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.