> For the complete documentation index, see [llms.txt](https://stackfi.gitbook.io/stackfi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stackfi.gitbook.io/stackfi/how-it-works.md). # How It Works Stackfi protocol has two sides to it: **Passive lenders:** asset lenders who seek passive yield and prefer lower risks. This can be seen similar to providing liquidity to Compound and getting cTokens back. Lenders' assets are utilized by others, for which they get APY. Any one can be a liquidity provider on Stackfi . See how. **Borrowers** - active traders, farmers, and even protocols who wish to increase their position by borrowing liquidity from the protocol at multiples of their collateral. The liquidity they borrow can be 10x of what their notional size is. This is the leverage power! See how. **Core Parts of Stackfi Protocol** One of the key aspects which actually makes this DeFi primitive possible are Credit Accounts (and Credit Managers), which “bind” together lenders and borrowers in this equation. More specifically, a Credit Account is an isolated smart contract (like a leveraged smart contract wallet) that holds user + borrowed funds, has liquidation thresholds, and has a list of Allowed Tokens and Protocols (in order to avoid attack vectors from malicious actors, like borrowing leverage and buying a self-created ERC20 token; or sending an amount to a malicious smart contract). ***Credit Accounts*** Stackfi does not silo the assets within its protocol. All trades and farming operations happen on BASE third-party protocols like Uniswap, Pancakeswap, AAVE , etc. Your assets never end up in custody of any one person or company. As such, Stackfi Protocol is not a trading platform / protocol. The protocol does not have its own order books, or control the secondary market liquidity. Therefore, there are no funding rates. Integrations possibilities are very broad, as Stackfi is built with composability at its core: The positions which traders and farmers take should be liquidated by third-party liquidators before the assets of liquidity providers would start being exposed to the downside. As such, the protocol returns the liquidity providers’ assets to the pools if all functions correctly and liquidators do their job. This is how Stackfi is able to provide composable leverage. Liquidations The protocol takes fees for different operations, where a part goes to Reserve Fund and part to different protocol operations. All parameters and spending depend on governance. The main logic is encapsulated in the core layer which supports operations for both protocol sides. It allows connecting customized pools with Credit Account managers without changing the internal codebase, and thus simplifying integrations. The goal of Stackfi is to be integrated with existing and new protocols in an open-source manner and provide leverage across many user bases and products. Because of its modularity, leverage can be given to even long-tail assets without increasing passive lending side risks. There could be segmentation of risks, personalized rates, collateral limits, and other mechanisms which allow modularity to shine and Stackfi to service different user groups. That could be farming, trading, sophisticated LP-ing, NFT and RWA leveraging, and so on.
--- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://stackfi.gitbook.io/stackfi/how-it-works.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.