Enzyme 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). Where 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 solves as a service; Enzyme solves it as a reusable smart-contract primitive. The protocol has processed over $7B in transaction volume and administers $200M+ in assets, across 8+ years with no reported security breach (enzyme.finance).
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) — 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). It is the same “work it, don't take it” guarantee karpatkey reaches with a 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). 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 (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). 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).
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). 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). This puts it in the same problem space as the 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).
Where it fits in the stack
On the DAO tooling stack, custody (Safe) and execution (Zodiac, on-chain governors) settle where funds live and how a vote moves them. Enzyme sits at the allocation layer above, alongside 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 exist because the mainstream DAO treasury is a passive 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 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 that members vote on and that executes 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 the earned, soulbound record of past voting, so a passive whale (v = 0) carries no weight; the same weighting sets each member's pro-rata share on exit. 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 and docs.enzyme.finance.
- Enzyme, From Melon to Enzyme (15 Dec 2020).
- Enzyme Finance, protocol repository (GPL-3.0 / BUSL-1.1, Enzyme Blue v4).