---
title: "Enzyme (on-chain asset management)"
url: "https://caper.network/wiki/dao-governance/tooling/treasury/enzyme"
updated: 2026-08-31
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Enzyme (on-chain asset management)

|  |  |
| --- | --- |
| **Tool** | [Enzyme](https://enzyme.finance) (formerly Melon) — non-custodial on-chain asset management |
| **Category** | Treasury asset management — the vault primitive that _works_ a treasury inside coded policies |
| **Trust model** | Non-custodial vaults: the manager can allocate across whitelisted protocols but cannot withdraw depositors' assets |
| **Founded** | Melonport AG, Zug (2016); rebranded to Enzyme [15 Dec 2020](https://medium.com/enzymefinance/from-melon-to-enzyme-b5b56512f40d) |
| **Token / governance** | `MLN`, governed on-chain by the Enzyme Council (formerly Melon Council) |
| **Track record** | Self-reported. Enzyme's homepage tile, read 24 Aug 2026, gives $7B+ volume, “+200M assets under technology”, “+8y” and “0 security breach” ([enzyme.finance](https://enzyme.finance)). The tile is undated and static; [DefiLlama](https://api.llama.fi/protocol/enzyme-finance) measured vault TVL at ~$91M on 24 Aug 2026, last above $200M on 27 Dec 2024 |
| **Related** | [Safe](/wiki/dao-governance/tooling/treasury/safe) · [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) · [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**[Enzyme](https://enzyme.finance)** is an Ethereum-based protocol for decentralized, on-chain asset management: it lets anyone “set up, manage and invest in customized on-chain investment vehicles” ([protocol repo](https://github.com/enzymefinance/protocol)). Where [Safe](/wiki/dao-governance/tooling/treasury/safe) answers _where a treasury's money sits_ and an on-chain governor answers _how a vote moves it_, Enzyme answers _how a treasury is actively worked_ — deployed into DeFi positions, rebalanced, and reported on — without the party doing the work ever holding the assets. It is the same active-management problem [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) solves as a service; Enzyme solves it as a reusable smart-contract primitive. Enzyme's homepage advertises over $7B in cumulative transaction volume, “+200M assets under technology”, “+8y” of operation and “0 security breach” ([enzyme.finance](https://enzyme.finance), read 24 August 2026). Those are self-reported, and the assets figure in particular is a fixed marketing tile rather than a live reading: [DefiLlama](https://api.llama.fi/protocol/enzyme-finance) put Enzyme's on-chain vault TVL at roughly $91M on 24 August 2026, against an all-time high near $248M in December 2024 and a last close above $200M on 27 December 2024. Cumulative volume and years elapsed can only grow, so they age harmlessly; assets under management can fall, so that one is a claim about the day it was written.

## The non-custodial vault

The core object is a **vault**. A manager (the vault owner) configures it; depositors deposit an accepted asset and receive **vault shares** that represent a pro-rata claim on the vault's holdings, so their share of any gains or losses tracks their share of the pool. The manager can then trade and allocate the pooled assets across the protocols the vault integrates — **Enzyme Blue** advertises end-to-end strategy management across 30+ DeFi protocols ([enzyme.finance](https://enzyme.finance)) — through standard _integration adapters_ for lending markets, DEXes, staking and derivatives.

The property that matters for a treasury is what the manager _cannot_ do. Assets live in the vault's own contract, and the manager's authority is scoped to moving them _between integrated positions_; there is no function that lets the manager send depositor assets to an arbitrary outside address. That is the whole meaning of “non-custodial” here: the worst a compromised or malicious manager can do is reallocate within the vault's permitted universe, never abscond with the balance ([docs.enzyme.finance](https://docs.enzyme.finance)). It is the same “work it, don't take it” guarantee [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) reaches with a [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) Roles Modifier bolted onto a Safe — here it is baked into the vault contract itself.

## Policies and fees: the manager's leash

A vault's constraints are set at configuration time and enforced on-chain. **Policies** bound the manager's discretion — which assets the vault may hold, which adapters and protocols it may touch, who is allowed to deposit, minimum/maximum deposit sizes and lock-ups. **Fees** are configurable too: management fees on assets under management, performance fees on gains (typically high-water-marked), and entrance/exit fees, all charged programmatically in shares ([docs.enzyme.finance](https://docs.enzyme.finance)). For a DAO, the policy set is the point: a treasury can hand a mandate to a manager and know, by code rather than by trust, exactly which venues and instruments that mandate can and cannot reach.

## From Melon to Enzyme

Enzyme began as **Melon**, built by **Melonport AG** — a company founded in Zug, Switzerland in 2016 by [Mona El Isa](https://enzyme.finance) (a former Goldman Sachs vice-president) and Reto Trinkler, with a single mandate to build “an asset management computer built on Ethereum.” The name came from the Greek _μéλλων_ (“future”). On 15 December 2020 the project announced its rebrand to **Enzyme**, phased in alongside the launch of Enzyme v2; the `MLN` token's ticker and contract address (`0xec67…1892`) were left unchanged, and the rename was driven partly by brand confusion with the bank BNY Mellon ([Enzyme](https://medium.com/enzymefinance/from-melon-to-enzyme-b5b56512f40d)). The codebase is open source under GPL-3.0 (with a BUSL-1.1 option for affiliated products), with a live Immunefi bug bounty and the current Enzyme Blue v4 developed and tested under Foundry ([protocol repo](https://github.com/enzymefinance/protocol)).

## Governance: MLN and the Enzyme Council

Enzyme is governed on-chain through its native token, `MLN`, and the **Enzyme Council** (the renamed Melon Council) — a delegate body that ratifies protocol changes, adds and vets integration adapters and price feeds, and manages the protocol's parameters. New DeFi integrations are gated through this process precisely because an unvetted adapter would widen every vault's attack surface at once, so the “asset universe” a manager can reach is itself a governed set rather than an open one ([docs.enzyme.finance](https://docs.enzyme.finance)). Governance here is doing operational security work, not just parameter-tuning.

## Who uses it — DAO treasuries

Enzyme vaults are compatible with both externally-owned accounts and multi-sig wallets, so a DAO can hold treasury assets in a vault and delegate active management to a manager (an internal working group or an outside firm) without surrendering custody or opening a withdrawal path out of the treasury ([enzyme.finance](https://enzyme.finance)). This puts it in the same problem space as the [treasury-management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) question every large DAO faces: a nine-figure balance sitting idle in stablecoins is itself a costly decision, and a vault with coded policies is one way to earn on it without hiring a custodian. Enzyme has since generalised into a product family — **Onyx** (vault-as-a-service for tokenized funds), **Blue** (multi-protocol strategy management), and **Myso** (on-chain options) — and extended to institutional infrastructure such as the Canton network ([enzyme.finance](https://enzyme.finance)).

## Where it fits in the stack

On the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), custody ([Safe](/wiki/dao-governance/tooling/treasury/safe)) and execution ([Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), on-chain governors) settle where funds live and how a vote moves them. Enzyme sits at the _allocation_ layer above, alongside [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey): once the treasury is safely held and governable, something still has to decide what the assets do. The two split the same layer differently — karpatkey is a professional manager that operates on your Safe through scoped roles; Enzyme is a self-serve vault contract into which you (or a manager you appoint) run a strategy under on-chain policies. Both keep the _work-it-don't-take-it_ boundary; they differ on whether you hire that discipline or configure it.

## How Caper approaches this

Enzyme and [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) exist because the mainstream DAO treasury is a passive [Safe](/wiki/dao-governance/tooling/treasury/safe), and turning it into a productive one means bolting an allocation layer on top and fencing that layer in with policies or roles. A [caper](/wiki/foundations/what-is-a-caper) removes the seam that layer spans. The treasury is a protocol-controlled vault _inside_ the contract, and capital moves only through a governed on-chain [proposal](/wiki/governance/proposals) that members [vote](/wiki/governance/voting) on and that [executes](/wiki/governance/execution) permissionlessly — an `INVEST` that withdraws treasury XRD and buys another caper's tokens on its bonding curve, or a `PAYOUT` that funds work. Vote weight is `(t·v)/(V·T)`, combining tokens held with an earned, soulbound record — minted 1 per ballot cast and 0.01 per XRD of gross trade value — so a holder who has done neither (`v = 0`) carries no weight; the same weighting sets each member's pro-rata share on [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). The trade-off is deliberate and honest. A caper has no vault owner to appoint and no continuous, discretionary rebalancing between votes — it forgoes exactly the always-on, professionally-managed DeFi yield that is Enzyme's whole reason to exist, in exchange for having no manager role and no custody boundary to trust at all. For a treasury that wants active, expert asset management, Enzyme is a reference primitive; a caper is the answer for one that wants every deployment of its capital to be a governed act of the membership by construction, not a mandate handed to a manager.

## References

- Enzyme, [enzyme.finance](https://enzyme.finance) and [docs.enzyme.finance](https://docs.enzyme.finance).
- Enzyme, [From Melon to Enzyme](https://medium.com/enzymefinance/from-melon-to-enzyme-b5b56512f40d) (15 Dec 2020).
- Enzyme Finance, [protocol repository](https://github.com/enzymefinance/protocol) (GPL-3.0 / BUSL-1.1, Enzyme Blue v4).