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.
- 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.
- 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.
- 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.
- 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.
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. We'll walk through your workflows and show you what the first integration looks like.
📚 Documentation | 🌐 Website | 💼 LinkedIn | 💻 Telegram (DM)