Many “vault infra” debates still revolve around a fundamental question: how much is onchain?

For builders, the real question is: where is execution policy enforced, and how brittle does it become when strategies must move fast?

This is where IPOR Fusion stands out. It implements an imperative–declarative model on top of a polymorphic vault runtime:

By contrast, the common “minimal vault + Merkle proofs” pattern encodes permissions as a Merkle tree of allowed calls: a root is anchored on-chain, and each execution must present a proof that the specific call (often including key parameters) is permitted.

The difference is not cosmetic. It is an architectural trade-off between agility with bounded risk (Fusion) and precision with operational rigidity (Merkle gating).


1. Policy-as-Code vs Policy-as-Data

Fusion: policy-as-code (plus declarative configuration)

Fusion pushes execution constraints into reusable code units:

Alpha can choose parameters and compose flows at runtime within those boundaries, but cannot escape them. This is “imperative freedom inside declarative safety”.

Merkle gating: policy-as-data

Merkle gating compresses permissions into a dataset:

This is highly explicit, but it creates a form of rigidity: strategy flexibility becomes proportional to how comprehensively the leaf set anticipates reality.