> For the complete documentation index, see [llms.txt](https://docs.auto.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.auto.finance/developer-docs/integrating/4626-compliance.md). # 4626 Compliance Autopools are implemented on top of the ERC-4626 vault standard but do no strictly adhere to the spec. The changes and important information for integration are listed below. ### View Functions as Non-Payable Due to how pricing and estimation is handled within the Autopool the following functions which are to be `view` functions per the spec are instead implemented as non-payable. Its important to note that these functions DO NOT actually make any state updates but utilize a "read-through-revert" pattern to simulate certain values: * `previewDeposit()` * `previewMint()` * `previewRedeem()` * `previewWithdraw()` * `maxDeposit()` * `maxMint()` * `maxRedeem()` * `maxWithdraw()` ### Slippage Depending on the conditions of the Autopool, the overall market, and the timing of the debt reporting process slippage may be encountered on both entering and exiting the Autopool. It is very important to always check the shares received and assets spent on entering, and the assets received and shares spent on exiting, are within your expectations and make sense according to your expected valuations. This is especially important during withdraw (read below on withdraw's future) where rounding/padding/slippage can burn far more shares than expected for no increase in returned value. ### Future functionality of Mint + Withdraw Do not use the `mint()` and `withdraw()` flows. While currently functional with the slippage caveats above, they will begin to revert in the future. These functions have consistently have more slippage, and use more gas, than their `deposit()` and `redeem()` counterparts due to the necessary calculations performed and can result in far worse results when exiting and more shares burned than redeem() would have required for the same value. ### Exiting the Autopool based on size The Autopools make an effort to support depositors of any size. Given the number of destinations (DEX's, lending markets, etc) that assets may be deployed to, this quickly becomes a trade-off game involving the assets being worked with, slippage conditions in the market, and the gas needed to retrieve them. The most gas-efficient route is to pull all the assets from either idle or from as few destinations as possible. This is the default behavior through `redeem()`. The Autopilot system keeps a cached set of swap routes on-chain to get out of the assets deployed to these destinations but, depending on size, these routes may be exhausted. To combat this, dynamic swap routes are able to be supplied by the caller. See [Large Withdrawals](/developer-docs/integrating/large-withdrawals.md) for more information. On the other end of the spectrum, when the size is so large that slippage outweighs the gas impact, additional functions are being added outside of the 4626 spec. These functions will return the pro-rata share of the underlying assets (LSTs, LRTs, USD derivatives, etc) owned by the user giving them complete control of how/when/if they return to the deposited asset. It is up to the caller to decide the method for performing the exit. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.auto.finance/developer-docs/integrating/4626-compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.