# Multicall by Colb Multicall by Colb is a feature that combines multiple operations into a single transaction. By executing operations atomically, Multicall ensures that either all operations succeed or all fail together. This prevents users from ending up in partial execution states, such as holding unwanted tokens due to a failed deposit or transfer. Executing operations separately introduces risk. For example, a user might successfully mint $USC tokens and then fail to deposit them into a strategy. In this case, the user would hold tokens they did not intend to keep and would need to perform additional transactions to resolve the situation. Multicall eliminates this risk by reverting the entire transaction if any operation fails, leaving the user's state unchanged. *** ### How it works? Multicall coordinates operations through specialized adapters. Each adapter handles a specific function, such as minting tokens, depositing into strategies, or other operations supported by registered adapters. When a user submits a batch request, Multicall first validates the user's permissions and then routes each operation to the appropriate adapter. Operations are executed sequentially, and the system ensures that all operations complete successfully. If any operation fails, the entire batch is reverted. Alternatively, users may choose to allow operations to continue even after a failure, depending on their requirements. Throughout this process, Multicall preserves the identity of the original user, ensuring that tokens, shares, or other assets are issued to the correct account. *** ### Adapters Multicall achieves its powerful composability through a modular system of specialized adapters. Each adapter is a smart contract responsible for executing one specific type of operation. #### Supported Adapters **EngineAdapter** Responsible for minting $USC tokens. * Receives approved collateral tokens from the user * Calculates and deducts protocol fees * Mints the corresponding amount of $USC * Sends the newly minted $USC directly to: * Another adapter in the same batch (most common pattern) * Any whitelisted address specified by the user **StrategyAdapter** Handles deposits into yield-generating strategies. * Works with Colb Liquids and standard ERC-4626 vaults * Expects to already hold the deposit tokens (typically received directly from a previous operation like EngineAdapter) * Performs the deposit into the target strategy/vault * Mints vault/strategy shares and transfers them directly to the original user (never to Multicall or the adapter itself) #### Rules & Security 1. **Whitelisting** Only adapters explicitly approved and whitelisted by protocol administrators can be used in Multicall batches. 2. **Caller Verification** Every adapter must internally verify that it is being called by Multicall (and not directly by any other address). This prevents bypass attacks and unauthorized usage. 3. **Original User Identity** Adapters never rely on msg.sender as the end-user. Instead, they query Multicall to retrieve the true original caller (the user who initiated the batch). This ensures all tokens, shares, and assets are always issued to the correct recipient - even across multiple nested operations. *** ### Usage Users must be whitelisted with the appropriate access level and must approve collateral tokens before submitting batch operations. Adapters must also be approved and verified to ensure they function correctly within the Multicall system. Adapters must be designed to operate safely within the protocol. Each adapter should only execute when called by Multicall and must handle token flows and user identity correctly. Users should calculate required amounts, including fees and potential price changes, and approve only the amounts necessary for each operation. Multicall should never be approved directly to spend user funds. *** ### Mint and Deposit Example A common use case involves minting $USC tokens and immediately depositing them into a strategy. Traditionally, this requires two separate transactions: first minting $USC and then depositing the tokens. If the first operation succeeds but the second fails, the user ends up holding unwanted tokens. Using Multicall, both operations are submitted as a single batch and can be executed atomically. The process works as follows: 1. The user calculates the required collateral, including fees, and approves it. 2. The user submits a batch request including the minting and deposit operations. 3. Multicall executes the minting operation first, sending $USC directly to the deposit adapter. 4. Multicall executes the deposit operation, issuing strategy shares to the user. 5. If both operations succeed, the transaction completes. If any operation fails, the entire transaction is reverted, and the user’s collateral remains untouched. This approach ensures that operations that must succeed together do so reliably and reduces the risk of unwanted token balances or additional corrective transactions. *** ### Best Practices * Calculate required amounts before submitting a batch and include potential fees or price changes. * Direct token flows between adapters to minimize unnecessary transfers. * Verify that adapters are whitelisted and functioning correctly before use. * Approve only the amounts required for each adapter. Never approve the Multicall contract directly. * Use precise calculations to reduce unnecessary approvals and costs. * Attach the `sweep()` function call after each adapter action to guarantee no funds are left in any adapter. --- # 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.colb.finance/payments-core-tech/multicall-by-colb.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.