# Mimic — full content > Mimic is a developer platform for building and scaling web3 products across chains. Teams define what should happen and when; Mimic handles execution securely — non-custodial, cross-chain and policy-controlled. This file contains the full text of every Mimic blog post in markdown. For a compact index of the site, see https://www.mimic.fi/llms.txt. --- # The Execution Gap in Onchain Asset Management > The gap between strategy and execution is the real bottleneck in onchain asset management. Mimic bridges it with programmable, policy-driven execution. Published: 2026-04-01 | Updated: 2026-04-01 | Author: Mimic Engineering Team | Tags: Asset Management, Mimic Platform | Source: https://www.mimic.fi/blog/the-execution-gap-in-onchain-asset-management ![](https://www.mimic.fi/blog/the-execution-gap-in-onchain-asset-management/X---The-Execution-Gap--in-Onchain-Asset-Management-1.png) Onchain asset management is growing exponentially through vaults and other execution systems. The strategy is getting more sophisticated, with risk evaluation across lending markets, target allocation, and custom logic, **but the execution is still outdated**. Manual operations, multisig signing, scripts, bots, and custom smart contracts are usually patched together on the execution side. The real bottleneck is turning strategy into transactions. Withdraw from one protocol. Approve another. Supply. Handle gas. Watch for reverts. Do it again tomorrow, across twelve vaults, on three chains. That's where things break. ## The gap between strategy and execution Onchain asset management has a missing middle. On one side, you have strategy: models, analytics, allocation decisions. On the other side, you have the blockchain: contracts, transactions, gas, and finality. Between them? Scripts. Cron jobs. Custom smart contracts. Bots held together with monitoring alerts. Maybe a dedicated ops person who knows which Safe needs which signer for which vault on which chain. It works until it doesn't. And it doesn't scale. There are no standards. Every new vault builds another set of scripts. Every new chain means another deployment pipeline. Every new mandate means more humans in the loop. The marginal cost of operating a new strategy grows linearly (or faster) with AUM. That's the opposite of what asset management should look like. ## What asset managers actually need When a team starts managing capital onchain at any real scale, the requirements converge quickly. They look something like this. 1. **Multi-protocol, multi-chain operations.** A real allocation strategy doesn't live inside one protocol. Rebalancing between Aave, Morpho, Spark, Fluid, and Compound (and more). Bridging USDC from Ethereum to Base when the yield differential justifies the cost. Claiming rewards from multiple different gauges and compounding them into the current target allocation. This all needs to work as a coordinated flow, not as five disconnected scripts. 2. **Emergency mechanisms.** When a protocol gets exploited, you need to pull capital out immediately. When gas spikes, you need to pause non-urgent operations. When a bridge gets stuck, you need to halt cross-chain flows and alert the team. Emergency handling should be built into the execution layer, not bolted on after the first incident. 3. **Auditability.** Institutional allocators need to know exactly what happened, when, and why. Every execution should produce a clear trail. Not only server logs, but onchain records that map back to the policies and constraints that governed them. 4. **Programmable, safe execution.** You need a layer between your strategy engine and the blockchain. Something that takes an allocation target and turns it into a sequence of onchain transactions (like withdraw, approve, supply) with constraints enforced onchain. Whitelisted contracts, slippage limits, volume caps, health factor floors. Not checks in your code. Policies on the blockchain. If your bot has a bug, the policy still holds. ## The problem with custom contracts The instinctive response is to build smart contracts for all of this. Encode your rebalancing logic into a contract. Deploy it. Audit it. But here's what happens in practice: your strategy changes every few weeks. Markets shift. New protocols launch. A lending market you were using gets deprecated. Your risk parameters evolve as you learn more about how your portfolio behaves under stress. Every change means rewriting contracts, redeploying, and re-auditing. Audit costs scale with contract complexity. Deployment introduces risk windows. And the more logic you put onchain, the larger your attack surface. There's a better model: keep the complex logic offchain, where it's easy to iterate, test, and update, and put only the constraints onchain. The constraints are simple, small, auditable. They define what's allowed. The execution logic decides what to do within those bounds. That's what programmable execution looks like. ![](https://www.mimic.fi/blog/the-execution-gap-in-onchain-asset-management/PB---The-Execution-Gap--in-Onchain-Asset-Management-1.png) ## Building safer systems for onchain asset management with Mimic Mimic is a programmable layer that sits between your strategy and the blockchain. You define execution logic offchain, in the form of functions that encode what should happen and when. Mimic enforces policies onchain: the constraints that guarantee nothing runs outside your boundaries. For an asset manager, the flow looks like this: Your team or system produces an allocation target. With Mimic, you can translate it into a sequence of onchain actions (withdraw, approve, supply, bridge, swap), and executes them through a policy-driven account. The policies (whitelisted contracts, method selectors, value caps, slippage limits) are signed onchain and can't be bypassed by the execution logic. No custom contracts to deploy or bots to maintain. Strategy logic lives where it's easy to change. The safety constraints live where they can't be changed without explicit authorization. This applies across the full range of what an onchain asset manager does: **Lending market rebalancing.** Your model identifies the best-yielding market for USDC across Aave, Morpho, Spark, and Compound. Mimic handles the cross-protocol flow: withdraw from the current position, approve the target protocol, and supply. Same-protocol, cross-protocol, and cross-chain rebalances, all executed through the same programmable layer. **Reward harvesting and compounding.** Claim rewards across protocols, swap to the target asset through a whitelisted DEX aggregator, and resupply. Triggered on a schedule or when accumulated rewards exceed a cost threshold. **Leveraged strategies.** Supply collateral, borrow, re-supply, and repeat until the target leverage ratio is reached. Health factor floors and maximum leverage caps enforced as onchain policies, not if-statements in a script. Automatic unwind when the health factor drops below a threshold. **Time-weighted token sales.** When your vaults receive token incentives, you need to sell them without moving the market. Mimic executes time-weighted sales, splitting the sell across intervals, enforcing minimum prices and slippage limits per execution, so the disposal is gradual, predictable, and auditable. ## Earning vaults: a concrete example One of the clearest applications of programmable execution for asset managers is an automated earning vault: a vault that continuously reallocates capital across lending protocols to maximize yield. Here's what a production-grade earning vault built on Mimic looks like. The vault accepts deposits in a base asset (say, USDC). Mimic monitors yields across protocols. When the yield differential between the current allocation and the best available market exceeds a threshold, Mimic executes the rebalance. But yield optimization alone isn't enough for institutional capital. The vault also needs **onchain compliance checks** (Chainalysis integration for OFAC screening on deposits), **granular pause mechanisms** (partial pause on deposits, emergency pause on all operations, emergency exit from all positions), **modular fee structures** enforced onchain, and **redemption processing** that unwinds positions in order, pulling from the least disruptive position first, respecting slippage limits. This isn't a theoretical design. These are the components teams need before institutional allocators will commit capital. ## What "institutional grade" actually means The phrase gets thrown around a lot. For onchain asset management, it comes down to a few specific things. **Deterministic execution.** Given the same inputs and state, the same thing happens every time. No race conditions, no timing-dependent behavior, no "it worked in testing but not in production." **Separation of risks.** Strategy logic, execution logic, and safety constraints are decoupled. The people who define the strategy don't need to touch the execution code. The people who set risk parameters don't need to understand the underlying protocol calls. Each layer can be reviewed, updated, and audited independently. **Onchain policy enforcement.** This is worth repeating: the constraints that protect capital must be enforced onchain, by the blockchain itself, not by your server or your bot. Whitelisted addresses. Approved method selectors. Maximum transaction values. Daily volume caps. Health factor minimums. Slippage ceilings. These aren't configuration files, they're signed onchain policies. **Operational continuity.** What happens when your ops lead leaves? When the person who wrote the rebalancing script gets sick? When the monitoring system goes down for two hours? Institutional-grade means the system keeps running correctly even when the humans aren't watching. The logic is encoded in the execution layer, not in someone's head. **Audit trail.** Every execution traces back to the policy that authorized it, the trigger that initiated it, and the onchain result. Not logs on a server. Not a Slack thread. An immutable, verifiable record. ## Where most teams start with Mimic If you're an asset manager running strategies onchain, whether you're managing vaults, DAO treasuries, or delegated capital, Mimic can help you achieve programmable execution in days instead of months. Most teams start with one or two recurring operations that are currently manual or script-dependent. A rebalancing flow. A fee collection routine. A reward harvesting cycle. Something that runs regularly, involves multiple protocol interactions, and would benefit from onchain policy enforcement. From there, the pattern repeats: encode the logic, define the constraints, let it run. Add the next workflow. Then the next. Mimic has processed over $9B in value across 450M+ transactions for teams like Trust Wallet, Trezor, and Ledger. The execution layer is production-tested. * * * If you're running strategies onchain_,_ [_reach out_](https://mimic.fillout.com/t/14mhpYTCR4us)_. We'll walk through your workflows and show you what the first integration looks like._ 📚 [Documentation](https://docs.mimic.fi/) | 🌐 [Website](https://www.mimic.fi/) | 💼 [LinkedIn](https://www.linkedin.com/company/mimic-finance) | 💻 [Telegram](https://t.me/stoczek_eth) (DM) --- # The Infrastructure Behind One-Click DeFi > Behind every single user click in DeFi, there are some of the most complex coordination problems in crypto. Let's explore what we don't see in the UI. Published: 2026-03-09 | Updated: 2026-04-01 | Author: Mimic Engineering Team | Tags: Mimic Platform | Source: https://www.mimic.fi/blog/the-infrastructure-behind-one-click-defi ![](https://www.mimic.fi/blog/the-infrastructure-behind-one-click-defi/The-Infra-blog.png) You click deposit, a wallet pops up, a signature, a short wait. And just like that, your funds are working. From an user perspective, modern DeFi feels more accessible (especially compared to the early days): a vault, a button, access to yield. But behind that single click is one of the most complex coordination problems in crypto. This article is about everything that we don't see in the UI. ## The illusion of simplicity One-click DeFi is not simple because DeFi itself became simple, it's because complexity was abstracted, pushed behind the curtains. When a user deposits funds into a smart contract, they are not just moving tokens, they are joining a system that must: - Observe markets - React to changing conditions - Execute transactions at the right time (and at the right gas cost) - Usually across chains - Under strict security requirements And of course without breaking the user's trust. The UI hides all of this, but the system underneath has to handle all of this continuously. ## The two types of one-click DeFi From the user’s perspective, there are two kinds of one-click DeFi: ### Passive one-click DeFi You deposit once and the protocol simply holds your position, earning yield or accruing interest, but never acting on your behalf. Lending on Aave or depositing into a basic pool feels one-click, yet risk and optimization remain your responsibility. ### Active (or automated) one-click DeFi It goes a step further: you still click once, but behind the scenes the system continuously monitors conditions, makes decisions, and executes transactions for you. Rebalancing, compounding, protecting against risk, and reacting to the market all happen without further user input. The UX looks the same, but the second replaces ongoing human attention with infrastructure. ![](https://www.mimic.fi/blog/the-infrastructure-behind-one-click-defi/image.png) [https://x.com/mimicfi/article/2030999687897989328/media/2030999462823260161](https://x.com/mimicfi/article/2030999687897989328/media/2030999462823260161) ## How one-click DeFi works behind the scenes From the UI, passive and active one-click DeFi look almost identical: you deposit, sign, and you’re done. Behind the scenes, however, they follow very different execution paths. ### Passive one-click DeFi: “set and forget” This is the simplest form of one-click DeFi. The system does very little for the user after the initial deposit. 1. **Deposit & accounting:** funds are deposited into a protocol (e.g. a lending market or pool) and tracked under your position. 2. **Static rules apply:** interest rates, rewards, or fees are calculated based on the parameters set by the protocol. 3. **External actors react:** for example if risk thresholds are crossed, other parties like liquidators, arbitrageurs or keepers might act. 4. **No decisions for the user:** the protocol never rebalances your position, reduces risk, or optimizes yield. You are the one that needs to keep track of the liquidation threshold. ### Active / automated one-click DeFi: “set and delegate” Active one-click DeFi replaces ongoing user attention with infrastructure.What happens behind the scenes: 1. **Deposit + strategy definition:** your deposit gets defined with certain conditions, thresholds, safeguards, and allowed actions. 2. **Continuous monitoring.** The system constantly observes: - Prices - Balances - Positions - Market conditions - Cross-chain state (when relevant) 3\. **Deterministic decision-making.** Predefined logic evaluates whether something should happen now: - Rebalance - Compound - Repay debt - Move liquidity - Exit a position 4\. **Coordinated execution.** The best execution path is selected, via intents or other methods. 5\. **Safeguards & verification.** Before funds move: - Slippage limits are enforced - Outputs are validated - Constraints are checked onchain 6\. **Recovery by design.** If an executor fails: - The system retries - Another executor takes over - The user never has to intervene Here, one-click means everything that should happen later is handled for you. ## Why one-click DeFi is hard to build and maintain Building this once is difficult, but maintaining it is harder. The system must survive market volatility, chain congestion, oracle failures, or constant attackers, among other threats. Check this post by bsmokes about building with 4337 wallets: [https://x.com/bsmokes](https://x.com/bsmokes) The real product is not the button. The button is just the interface. The real product is all the infrastructure that runs the coordination, execution, and keeps working after the user closes the app. ## Build one-click DeFi with Mimic > Building in DeFi is hard. You need systems that monitor markets, evaluate conditions, trigger transactions, and keep everything running across chains. Mimic provides that infrastructure through a development platform: 1. Define your DeFi logic as programmable functions (with conditions, triggers, thresholds) 2. Or choose from ready-to-use templates 3. Let Mimic handle monitoring, coordination, and execution No custom scripts, smart contracts to deploy, or execution infrastructure to maintain. Just ship new features and products. Users click once. Mimic runs everything behind the scenes. Explore more at [docs.mimic.fi](http://docs.mimic.fi/) --- # The Fastest Way to Build a DeFi App in 2026 > Most DeFi apps don't fail because teams can't write contracts, they fail because of the the infrastructure deployment and maintenance. Let's explore the fastest way to build a DeFi app in 2026. Published: 2026-03-04 | Updated: 2026-03-04 | Author: Mimic Engineering Team | Tags: Mimic Platform | Source: https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026 ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/build-fast-1-social2-1.png) Five years ago, writing smart contracts was rare. But today, Solidity is taught in universities and bootcamps, and AI can write contracts in seconds. The number of people who can write DeFi code has exploded. But here's the truth: Most DeFi apps don't fail because teams can't write contracts. They fail because of what comes next, the infrastructure deployment and maintenance. - Bots - Gas abstraction - Retry logic - Monitoring - Server maintenance AI can help you write contracts faster, but it does not remove the execution, coordination, and settlement problems. That's where most teams spend months, or give up entirely. ## The Real Bottleneck in DeFi Development In 2026, the real bottleneck in DeFi is not Solidity, it's execution infrastructure. Let's say you've written the smart contracts needed, compiled and tested them, maybe even audited. It feels like you're on the finish line, but you're not. Writing the smart contracts is just the beginning. The real work starts when your DeFi apps needs to run reliably in the real world. The moment your app goes live, you now need to handle: - Transaction monitoring across chains - Gas price volatility - Settlement guarantees - Oracle integrations - Liquidity and execution routing - Secure key management for any bots and human operators - Alerting and monitoring And none of this is your actual product, it's just what's needed to keep it alive. ## The Costs in DeFi Development 1. **Time cost** Infrastructure maintenance doesn't just add complexity, it adds a lot of time to the development. Time spent writing contracts, bots, scripts. Time spent fixing errors, monitoring dashboards. 2. **Financial cost** Auditing, running nodes or RPC providers, paying engineers, covering failures, managing gas across chains... all the costs add up. 3. **Mental energy** This is harder to measure, but instead of managing infrastructure, you could use your mental energy to make your product better. ## The Solution: Build the Product, Delegate the Execution What if building a DeFi app didn't require you to become an infra company? What if you didn't need to manage bots, gas, retries, or servers? ### **Introducing Mimic** Mimic is a developer platform that allows teams to build blockchain applications without dealing with low-level complexities. Instead of building and maintaining custom infrastructure, builders can focus on product logic while Mimic handles execution, reliability, and security under the hood. Developers define what should happen and when, Mimic handles how it happens: 1. Write simple, familiar code to define what should happen and when 2. Mimic handles execution, data sourcing, coordination, and safeguards 3. A decentralized network of three layers powers the platform 4. Logic is compiled, executed, and settled with security guarantees If you want to learn more, check out our documentation at [**docs.mimic.fi**](http://docs.mimic.fi/). ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/build-fast-1-PostBreaks01.png) ## Examples of Building With Mimic We built some real mini-apps on top of Mimic to show how development with our platform could look like. Each of these examples is simple at the surface: a front-end that connects to Mimic functions. These apps do not rely on custom scripts, RPCs, or cross-chain swaps; all of that is handled and abstracted by the platform. The app only define the parameters, as a user would interact with any front-end you create to interact with Mimic. Here are four examples you can explore today: ### Swap App A simple swap interface where users define de source and destination token and chain, amount, and slippage. ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/Screenshot-2026-02-27-at-11.39.02.png) The frontend defines what the user wants, and Mimic handles how it happens. Link: [https://github.com/mimic-fi/ethereum-swap-app-with-mimic](https://github.com/mimic-fi/ethereum-swap-app-with-mimic) ### Automated Savings A recurring savings app that deposits funds into Aave automatically. Users define the asset, chain, amount, and frequency. ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/Screenshot-2026-02-27-at-11.43.04.png) The user can focus on the savings logic, and Mimic ensures it get executed on time. Link: [https://github.com/mimic-fi/aave-savings-app-with-mimic](https://github.com/mimic-fi/aave-savings-app-with-mimic) ### Cross-Chain Subscriptions A subscription payment system where users can: - Pay in any supported token - On any supported chain - On a recurring schedule - Without holding native gas tokens ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/Screenshot-2026-02-27-at-11.43.25.png) Mimic coordinates execution across chains atomically. From the product side, you’re just defining a recurring payment rule. Link: [https://github.com/mimic-fi/cross-chain-subscription-payments-with-mimic](https://github.com/mimic-fi/cross-chain-subscription-payments-with-mimic) ### Card Auto Top-Up A programmable card top-up system. Users define the balance threshold, the amount they want to send, the token (and chain) they want to send, and the slippage. ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/Screenshot-2026-02-27-at-11.43.36.png) Mimic monitors, routes, swaps, settles, and guarantees the top-up when conditions are met. The product only defines the policy. Link: [https://github.com/mimic-fi/card-top-up-with-mimic](https://github.com/mimic-fi/card-top-up-with-mimic) ### Check the examples here You can check all these mini-apps and their source code here: 👉 [https://github.com/mimic-fi](https://github.com/mimic-fi) ## Unlock easier DeFi development with Mimic Each of these apps would traditionally require: - Backend infrastructure - Bots and cron jobs - Cross-chain bridges - Gas abstraction layers - Monitoring dashboards - Retry systems - Dedicated DevOps With Mimic, they require none of that. You define deterministic logic. Mimic compiles it, coordinates it, executes it, and settles it securely. If you start using Mimic to build DeFi apps, you’ll notice something immediately: The complexity is gone. ## Try Mimic Now! **Available on Arbitrum, Base, Base Sepolia, Ethereum, Gnosis, Optimism, and Sonic.** ![](https://www.mimic.fi/blog/the-fastest-way-to-build-a-defi-app-in-2026/try-mimic-now.svg) Start simplifying how you code, execute, and scale blockchain projects. **Let Mimic handle the busy work while you focus on building.** 🐦 [X (Twitter)](https://x.com/mimicfi) | 📚 [Documentation](https://docs.mimic.fi/) | 💬 [Discord](https://discord.mimic.fi/) | 💻 [Telegram](https://t.me/+cBCtvvZuGpplNmY8) 🌐 [Website](https://www.mimic.fi/) | 🌀 [Farcaster](https://farcaster.xyz/mimicfi) | 💼 [LinkedIn](https://www.linkedin.com/company/mimic-finance) --- # What is Mimic? > Mimic is a developer platform that allows teams to build blockchain applications without dealing with low-level complexities. Define what should happen and when, Mimic handles how it happens. Published: 2026-02-23 | Updated: 2026-03-24 | Author: Mimic Engineering Team | Tags: Mimic Platform | Source: https://www.mimic.fi/blog/what-is-mimic ![](https://www.mimic.fi/blog/what-is-mimic/what-is-Mimic-blog.png) Building onchain is still harder than it should be. Not because writing logic is difficult, but because running that logic is complex and requires infrastructure maintenance. Mimic exists to remove that burden. Our north star is simple: > A world where building a blockchain product feels no harder than building any other distributed system. ## What is Mimic? Mimic is a programmable layer for onchain products. Teams define execution logic offchain and enforce it onchain through policies, with no smart contracts to write, audit, or redeploy. Wallets, AI agents, asset managers, and fintechs use Mimic to ship features like DCA, subscriptions, portfolio rebalancing, and fee collection at a fraction of the cost and time. Since 2022, Mimic has processed over $9B in assets across 450M+ transactions, powering projects like Ledger, Trust Wallet, Safe, and Trezor. ## What builders can unlock with Mimic Mimic removes the friction of traditional blockchain development. For every smart contract or script deployed, there are multiple steps to manage them: servers, RPCs, bugs, updates, protocol changes, and more. Mimic allows you to just focus on what you want to achieve, and forget about the rest. By combining serverless functions, intent-based execution, and built-in policies, Mimic turns fragmented blockchain workflows into a cohesive and deterministic system. This enables developers to build and scale applications, agents, and protocols with greater speed, confidence, and operational clarity, while retaining full transparency and control over system behavior. With Mimic, teams can: - Build onchain without managing infrastructure - Express business/product logic in familiar code - Run that logic with security guarantees - Easily scale across chains - Build real blockchain products faster ## Who is Mimic for? Mimic is for companies and builders that: - Want to ship blockchain products, not infrastructure - Care about reliability, security, and scale - Need higher-level building blocks, not raw access - Are building applications, agents, or protocols meant to scale Whether you’re a solo dev shipping your first blockchain product or a mature team running production systems, Mimic is designed to meet you where you are, and grow with you. ![](https://www.mimic.fi/blog/what-is-mimic/what-is-mimic-blog-post-break.png) ## Why we exist Blockchain adoption doesn’t fail because of ideas, it fails because teams get stuck shipping infrastructure instead of products. Mimic exists to empower companies to build blockchain products by simplifying access to blockchain infrastructure. ## What we believe - Abstraction is not a luxury, it is a requirement for adoption. - Real products require orchestration, guarantees, and execution logic. - Writing logic is easy. Running it safely, repeatedly, and at scale is not. - If a team can’t ship faster with it, it’s not an abstraction, it’s friction. Everything we build is measured against one question: Does this help teams ship reliable blockchain products faster? ## Our building philoshopy - We start from product needs, not protocols - We design for production from day one - We abstract complexity without hiding consequences Mimic is not about adding another layer for the sake of it, it’s about removing everything teams shouldn’t have to build themselves. ## How Mimic works At a high level, Mimic is a blockchain development platform that lets teams build and run onchain logic without managing infrastructure: - Developers write simple, familiar code to define what should happen and when - Mimic handles execution, data sourcing, coordination, and safeguards - A decentralized network of three layers powers the system - Logic is compiled deterministically, executed trustlessly, and finalized with cryptographic guarantees - Builders can focus on shipping products, not maintaining smart contracts, bots, or automation systems If you want to learn more, check out our documentation at [**docs.mimic.fi**](http://docs.mimic.fi/). ## The future of blockchain development We believe blockchain development should evolve the same way cloud development did. Building a blockchain product should feel no harder than building any other distributed system. Infra gets abstracted, execution becomes reliable and easy to build on top of, and developers focus on the product, not on maintenance. Mimic’s north star is a future where blockchain development is no longer “special.” Just simple, programmable, and production-ready. If you’re building blockchain applications and want to move faster (without giving up control), Mimic is built for you. ## Try Mimic Now! **Available on Arbitrum, Base, Base Sepolia, Ethereum, Gnosis, Optimism, and Sonic.** ![](https://www.mimic.fi/blog/what-is-mimic/try-mimic-now.svg) Start simplifying how you code, execute, and scale blockchain projects. **Let Mimic handle the busy work while you focus on building.** 🐦 [X (Twitter)](https://x.com/mimicfi) | 📚 [Documentation](https://docs.mimic.fi/) | 💬 [Discord](https://discord.mimic.fi/) | 💻 [Telegram](https://t.me/+cBCtvvZuGpplNmY8) 🌐 [Website](https://www.mimic.fi/) | 🌀 [Farcaster](https://farcaster.xyz/mimicfi) | 💼 [LinkedIn](https://www.linkedin.com/company/mimic-finance) --- # Migration Guide: From Gelato Web3 Functions to Mimic > Are you looking to migrate from Gelato Web3 Functions (Automation) before they shut down? Use Mimic, a clean, low-risk, and battle-tested alternative. Published: 2026-02-09 | Updated: 2026-02-09 | Author: Mimic Engineering Team | Tags: Mimic Platform, Onchain Automation, Mimic Guides | Source: https://www.mimic.fi/blog/migration-guide-from-gelato-web3-functions-to-mimic ![](https://www.mimic.fi/blog/migration-guide-from-gelato-web3-functions-to-mimic/Migration-Guide_-From-Gelato-Web3-Functions-to-Mimic.png) This guide is written for teams migrating off Gelato Web3 Functions before they shut down, and looking for a clean, low-risk and battle-tested alternative. It focuses on replacing the automation that used to live in Gelato towards Mimic. ## What Gelato Web3 Functions were typically used for **Onchain logic and data** - Fetching prices or external signals from APIs - Refreshing oracles or updating interest rates - Write here the different use cases **Triggers and schedules** Gelato provided a flexible trigger system that set up when the logic should run: - Time-based (cron, interval), - Event-based (onchain events), - State-based (every block). **Execution + operations** Gelato also handled submitting transactions, managing whitelisted executors, and retrying functions. ## Mapping Gelato to Mimic concepts In order to achieve a successful migration, we want to show how Gelato's concepts translate into the Mimic system. ![](https://www.mimic.fi/blog/migration-guide-from-gelato-web3-functions-to-mimic/Screenshot-2026-02-09-at-13.59.42.png) You can easily migrate all of Gelato's Web3 Functions into Mimic Functions, that also support TypeScript. - A Mimic Function is executable logic onchain that runs on demand of the user - You can group multiple Functions together to create a project - And add multiple triggers to run your functions As you might see, even tho the Mimic system uses a different technical approach than Gelato, some of the workflows are similar, allowing you to quickly rewrite your Web3 Functions into Mimic. ## How to start the migration of Gelato Web3 Functions into Mimic We recommend a step-by-step approach to have everything running smoothly in a short time. **Migration checklist:** 1. Inventory of existing Gelato functions 2. Classify by criticality (leave the most critical for the end) 3. Find the TS code of your Web3 Functions 4. Translate it into Mimic functions 5. Test and deploy one-by-one 6. Cut Gelato Web3 functions gradually Before starting the deployment in Mimic, let’s figure out the differences between Gelato Functions and Mimic Functions. ### Example: **Automated Fee Consolidation** The goal of this function is to swap multiple tokens for USDC, and transfer the USDC to another account. How to provide the configuration for the function: - In Gelato (schema.json) ```json { "web3FunctionVersion": "2.0.0", "runtime": "js-1.0", "memory": 128, "timeout": 30, "userArgs": { "proxyAddress": "string", "tokenInAddresses": "string[]", "tokenOutAddress": "string", "minOutAmount": "string" } } ``` - In Mimic (manifest.yaml) ```yaml version: 1.0.0 name: Collect Function description: Swaps all user tokens for USDC and sends the USDC to a recipient inputs: - chainId: int32 - slippageBps: uint16 # e.g., 50 = 0.50% - recipient: address ``` Then the function itself: - In Gelato ```tsx import { AutomateSDK, Web3Function } from "@gelatonetwork/automate-sdk"; import { task } from "hardhat/config"; import "dotenv"; task("consolidate", "Automatically swap accrued tokens") .addParam("in", "list of tokens to swap, separated by commas") .addParam("out", "unified token to swap input tokens for") .addParam("amount", "minimum output amount denominated in output tokens") .setAction(async (args, { ethers, w3f }) => { const apiKey = process.env.ONEINCH_API_KEY; if (!apiKey) throw new Error("Consolidate: missing 1inch API key in .env"); const tokensIn = (args.in as string).split(" "); for (const token of tokensIn) { if (!ethers.utils.isAddress(token)) throw new Error("Consolidate: invalid input token address"); } const tokenOut = args.out as string; if (!ethers.utils.isAddress(tokenOut)) throw new Error("Consolidate: invalid output token address"); const amount = BigInt(args.amount); if (!amount) throw new Error("Consolidate: invalid amount"); // deploy W3F to IPFS console.log("Deploying W3F to IPFS."); const consolidateW3f = w3f.get("consolidate"); const cid = await consolidateW3f.deploy(); console.log(`Deployed W3F hash ${cid}.`); // create W3F task console.log("Creating W3F task."); const [deployer] = await ethers.getSigners(); const chainId = await deployer.getChainId(); const automate = new AutomateSDK(chainId, deployer); const web3Function = new Web3Function(chainId, deployer); const proxy = await automate.getDedicatedMsgSender(); const { taskId, tx } = await automate.createBatchExecTask({ name: "Automated Fee Consolidation", web3FunctionHash: cid, web3FunctionArgs: { proxyAddress: proxy.address, tokenInAddresses: tokensIn, tokenOutAddress: tokenOut, minOutAmount: amount.toString(), }, }); await web3Function.secrets.set({ key: apiKey }, taskId); await tx.wait(); console.log( `Created consolidate task: ); }); ``` - In Mimic ```tsx import { Arbitrum, Base, ChainId, environment, ListType, log, Optimism, SwapBuilder, Token, USD, } from '@mimicprotocol/lib-ts' import { inputs } from './types' export default function main(): void { const chainId = inputs.chainId const context = environment.getContext() // Find tokens with user's balance > 0 const amountsIn = environment.relevantTokensQuery(context.user, [chainId], USD.zero(), [], ListType.DenyList).unwrap() if (amountsIn.length == 0) { log.info(`No tokens found on chain ${chainId}`) return } const USDC = getUsdc(chainId) for (let i = 0; i < amountsIn.length; i++) { const amountIn = amountsIn[i] const amountOut = amountIn.toTokenAmount(USDC).unwrap() const minAmountOut = amountOut.applySlippageBps(inputs.slippageBps as i32) // Note that the recipient will receive the USDC SwapBuilder.forChain(chainId) .addTokenInFromTokenAmount(amountIn) .addTokenOutFromTokenAmount(minAmountOut, inputs.recipient) .build() .send() log.info(`Adding swap of ${amountIn} to ${minAmountOut} on chain ${chainId}`) } } function getUsdc(chainId: i32): Token { if (chainId == ChainId.ARBITRUM) return Arbitrum.USDC if (chainId == ChainId.BASE) return Base.USDC if (chainId == ChainId.OPTIMISM) return Optimism.USDC throw new Error('Invalid chain') } ``` You can learn more about how to write a Mimic function in our documentation: [https://docs.mimic.fi/](https://docs.mimic.fi/) And library: [https://docs.mimic.fi/developers/library](https://docs.mimic.fi/developers/library) ![](https://www.mimic.fi/blog/migration-guide-from-gelato-web3-functions-to-mimic/Migration-Guide_-From-Gelato-Web3-Functions-to-Mimic--2-.png) ## What is Mimic and how does it work? Mimic is a developer platform to build blockchain apps, unlocking automation for your Web3 stack in a simple way. Using the Mimic platform consists of the following steps: 1. Start your function: start a working directory to create your function 2. Define the manifest: it’s a .yaml file where you write the metadata (name, description, version), parameters, and other things 3. Generate types 4. Write the function logic 5. Build: validate and compile the function logic 6. Deploy: upload your build to the Mimic registry, so it’s available to execute ## Useful resources to start with Mimic Starting guide: [https://docs.mimic.fi/examples/build-a-simple-function](https://docs.mimic.fi/examples/build-a-simple-function) How to understand the platform quickly: [https://www.mimic.fi/blog/understand-mimic-in-10-minutes](https://www.mimic.fi/blog/understand-mimic-in-10-minutes) ## Migrate Gelato Web3 Functions to Mimic and achieve more Mimic has a similar approach to Gelato Automation, but also lets you achieve even more: 1. **Multi-step workflows:** you can compose logic that can be chained, and reused, enabling solutions to cover any use case you need. Just chain multiple functions or have them listen to each other to activate. 2. **Cross-chain by design:** one function or project can safely operate across multiple networks. 3. **Built-in safety engine:** Mimic includes native safeguards and policies (constraints that define what must and must never happen). For teams coming from Gelato automation, Mimic feels close enough that you can migrate quickly, while still unlocking more advanced use cases over time. ## Need help migrating from Gelato Web3 Functions? We’re always happy to help! You can reach us out here: Discord: [https://discord.mimic.fi/](https://discord.mimic.fi/) Telegram: [https://t.me/+cBCtvvZuGpplNmY8](https://t.me/+cBCtvvZuGpplNmY8) ![](https://www.mimic.fi/blog/migration-guide-from-gelato-web3-functions-to-mimic/Migration-Guide_-From-Gelato-Web3-Functions-to-Mimic--3-.png) --- # Gelato Web3 Automation is Ending: Use Mimic > Gelato Web3 Functions are ending in March of 2026. If your team used Gelato for automation, Mimic is a great alternative. Explore more in this blog! Published: 2026-02-09 | Updated: 2026-02-09 | Author: Mimic Engineering Team | Tags: Mimic Platform, Onchain Automation | Source: https://www.mimic.fi/blog/gelato-web3-automation-is-ending-use-mimic ![](https://www.mimic.fi/blog/gelato-web3-automation-is-ending-use-mimic/Gelato-Web3-Automation-Is-Ending_-Use-Mimic.png) Gelato's automation platform (Web3 Functions) will be deprecated on March 31 2026. ![](https://www.mimic.fi/blog/gelato-web3-automation-is-ending-use-mimic/Screenshot-2026-02-09-at-14.24.22.png) *You might have seen this on Gelato's app.* After years of powering automation for key Web3 applications and protocols, Gelato is shifting focus, due to their great success of their rollup-as-a-service (RaaS) business, where it has seen massive adoption and growth. For teams that relied on Gelato Web3 Functions to run critical automation, this marks an important transition point: workflows that used Gelato's automation will stop soon unless they are migrated to a new service. This posts explains who is affected, what breaks with the shut down, and why Mimic is especially relevant right now. ## What is ending? Gelato Web3 Functions are being deprecated, Gelato's automation product. They acted as a backend or execution layer. Developers could write TypeScript functions, deploy them to IPFS, and give the execution to the Gelato system. They allowed cron jobs, recurring transactions, onchain events, and more. That entire product line is now being shut down. ## How does this impact existing Gelato automation users? If your application relied on Gelato Web3 Functions, you’re affected. This includes teams using Web3 Functions for: - Off-chain data ingestion (APIs, subgraphs, analytics) - Conditional onchain execution - Scheduled automation (cron jobs, interval tasks) - Event-driven workflows - Large-scale operational systems (liquidations, treasury ops, rebalancing) All your triggers, recurring jobs, functions, logs, and more will stop functioning. If Web3 Functions were part of your infrastructure, now is the time to look for another solution. ![](https://www.mimic.fi/blog/gelato-web3-automation-is-ending-use-mimic/Gelato-Web3-Automation-Is-Ending_-Use-Mimic--2-.png) ## The alternative: Mimic Mimic is a developer platform to build blockchain apps, unlocking automation for your Web3 stack in a simple way. You can easily migrate all of Gelato's Web3 Functions into Mimic Functions, that also support TypeScript. - A Mimic Function is executable logic onchain that runs on demand of the user. - You can group multiple Functions together to create a project. - And add multiple triggers to run your functions. Mimic has a similar approach to Gelato Automation, but also lets you achieve even more: 1. Multi-step workflows: you can compose logic that can be chained, and reused, enabling solutions to cover any use case you need. Just chain multiple functions or have them listen to each other to activate. 2. Cross-chain by design: one function or project can safely operate across multiple networks. 3. Built-in safety engine: Mimic includes native safeguards and policies (constraints that define what must and must never happen). For teams coming from Gelato automation, Mimic feels close enough that you can migrate quickly, while still unlocking more advanced use cases over time. ## Quickly understand Mimic If you're evaluating how to replace Gelato Web3 Functions with Mimic Functions, or planning a migration before March 31st 2026, start here: - [Understand Mimic in 10 minutes](https://www.mimic.fi/blog/understand-mimic-in-10-minutes) - [Migration Guide: From Gelato Web3 Functions to Mimic](https://www.mimic.fi/blog/migration-guide-from-gelato-web3-functions-to-mimic) ### Need help migrating from Gelato Web3 Functions? We’re always happy to help! You can reach us out here: Discord: [https://discord.mimic.fi/](https://discord.mimic.fi/) Telegram: [https://t.me/+cBCtvvZuGpplNmY8](https://t.me/+cBCtvvZuGpplNmY8) ![](https://www.mimic.fi/blog/gelato-web3-automation-is-ending-use-mimic/Gelato-Web3-Automation-Is-Ending_-Use-Mimic--3-.png) --- # Understand Mimic in 10 Minutes > Mimic removes the friction of traditional blockchain development, enabling developers to build and scale onchain with greater speed, confidence, and operational clarity. Let's understand Mimic quickly! Published: 2026-02-02 | Updated: 2026-02-05 | Author: Mimic Engineering Team | Tags: Mimic Platform | Source: https://www.mimic.fi/blog/understand-mimic-in-10-minutes ![](https://www.mimic.fi/blog/understand-mimic-in-10-minutes/BLOG_What-is-mimic-protocol-04--2-.png) Mimic is a developer platform for building blockchain applications, agents, and protocols faster and easier. You can write what should happen onchain and when in simple, familiar code, without having to deploy smart contracts, or manage servers, nodes, wallets, keys, scripts, or bots. ## Why use Mimic Mimic removes the friction of traditional blockchain development, enabling developers to build and scale onchain with greater speed, confidence, and operational clarity, while retaining full transparency and control over how things should work. With Mimic, teams can: - Build onchain in less steps - Express business/product logic in familiar code - Run that logic with security guarantees - Easily scale across chains - Replace cron jobs, scripts, and bots - Access powerful onchain automation ## Understanding Mimic quickly In Mimic, you create what we call **functions**: executable logic that runs on demand without managing servers or infrastructure. Then we have a **project**, which is a group of different functions. For advanced use cases, when a single function doesn’t cover the entire workflow, or as a way to use a function in multiple use cases without having to write a new one from scratch. Inside each function you can set up different triggers (price, events, thresholds, etc.) and also policies (onchain constraints that limit what can be executed on a user’s behalf). ## The Mimic workflow The process consists of the following steps: 1. Start your function: start a working directory to create your function. 2. Define the manifest: it’s a .yaml file where you write the metadata (name, description, version), parameters, and other things. 3. Generate types. 4. Write the function logic. 5. Build: validate and compile the function logic. 6. Deploy: upload your build to the Mimic registry, so it’s available to execute. Let’s start using Mimic! ![](https://www.mimic.fi/blog/understand-mimic-in-10-minutes/BLOG_What-is-mimic-protocol-03--3-.png) ## 1\. Start your function Let's start a new working directory to develop your function. To do that you can run the following command: ``` npx @mimicprotocol/cli init ./my-mimic-task ``` ## 2\. Define the manifest The manifest file provides the configuration for your task, including: - **Metadata**: Name, description, and version of the function. - **Inputs**: Parameters required by the function logic. - **ABIs**: Smart contract ABIs (description of a contract’s public interface) to generate type-safe interfaces for the task. The manifest can be located in your working directory as a manifest.yaml file. Here is an example on how the manifest looks like: ```yaml version:1.0.0 name:Transfer based on USD threshold description:Automated task to execute parameterized transfers based on balance threshold in USD inputs: -chainId:uint32 -token:address -amount:string# e.g., '10.2' = 10.2 of the given token -recipient:address -maxFee:string# e.g., '0.01' = 0.01 of the given token -thresholdUsd:string# e.g., '30.5' = 30.5 USD abis: -ERC20:./abis/ERC20.json ``` This manifest file defines different inputs that will be accessible from the task logic code thanks to the types generation process that will be explained in the next section. For a more detailed explanation about the manifest, [check our documentation](https://docs.mimic.fi/examples/build-a-simple-task#manifest-definition). You can also find different examples of manifests here: [https://github.com/mimic-protocol/examples/tree/main/examples](https://github.com/mimic-protocol/examples/tree/main/examples) ## 3\. Generate types This steps allows you to validate the manifest definitions and generate the corresponding code to access both your declared inputs and the contract objects for your declared ABIs. To do this you can run the `codegen` command using the CLI: ``` yarn mimic codegen ``` ## 4\. Write the function logic This is the main point of Mimic: focusing on what you want to happen, and when. Inside each function, you can write different types of triggers, schedules, events, etc. In this step you are going to expand what you defined in the manifest.yaml. The function logic is implemented in AssemblyScript and must export: 1. **Input type**: The generated `inputs` type from the manifest.. 2. **Main function**: The core function logic, which receives the inputs as an argument. For now Mimic functions allows creating three types of intents: - Transfers - Generic calls - Cross-chain swaps You can find different examples of functions here: [https://github.com/mimic-protocol/examples/tree/main/examples](https://github.com/mimic-protocol/examples/tree/main/examples) ## 5\. Build The compile process converts your task logic and manifest into deployable artifacts. Basically it takes your manifest and function logic and transforms it into something you can upload to the Mimic registry to run at any time you want. For this, just run the compile command: ``` yarn mimic compile ``` ## 6\. Deploy Once your function has been compiled into an artifact, you can upload it to the network so others can discover it. To do this you can run the `deploy` command using the CLI: ``` yarn mimic deploy --api-key [DEPLOYMENT_KEY] ``` You can generate a deployment key from the explorer app: Just go to: [https://protocol.mimic.fi/](https://protocol.mimic.fi/) Login using your wallet, and click on “generate API key”.