> For the complete documentation index, see [llms.txt](https://docs.xy.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xy.finance/single-bridge-integration/ybridge-contract-integration/legacy-integrate-y-pool-contract/legacy-maximum-available-liquidity.md).

# (Legacy) Maximum Available Liquidity

{% hint style="warning" %}
If you're going to initiate a cross-chain request, please make sure there's enough buffer liquidity on the target chain since there will always be a time gap between reading the stats and executing the request.
{% endhint %}

The major concept is that we can get the rough available liquidity by getting the balance of the `YPoolVault` contract If the deposit token is native token. If it's ERC20-like token, we get the balance of the `YPoolVault` contract from the deposit token contract.

However, the balance we get directly from the contract is just a rough number since some of the balance might belong to the XY worker.

As mentioned in the **public states** in [(Legacy) Integrate Y Pool Contract](/single-bridge-integration/ybridge-contract-integration/legacy-integrate-y-pool-contract.md), some of the fees belong to XY worker. Therefore we should deduct those part if we are aiming higher accuracy of available liquidity.

If the deposit token of a `YPoolVault` is the native token, `depositAndWithdrawFees` should be deducted.

`closeSwapGasFees` should always be deducted whether the deposit token of a `YPoolVault` is the native token or not

The last uncertainty is the asset accidentally sent to the `YPoolVault`. This kind of asset will NOT be withdrawn immediately. Therefore, please make sure there's enough buffer when you're trying to initiate a cross-chain request directly with the smart contracts.