The Programmable Vault Stack: Customize Behavior Without Rewriting the Core

Building infrastructure that supports every type of vault the market will need is an abstraction problem.

A tokenized money market fund, a multi-strategy DeFi allocator, and a cross-chain distribution vehicle all need different rules around who can hold the token, how deposits and redemptions work, what fees apply, and how pricing is calculated. But they all share the same underlying mechanics: accounting, settlement, cross-chain messaging, and access controls.

Centrifuge's approach is to make the core immutable and secured, and make everything else customizable. The result is a stack where builders configure behavior without writing security-critical code. The core enforces accounting invariants that modules cannot violate: a buggy price manager can misprice shares, but it cannot fabricate assets or bypass settlement.

Finding the right abstractions

The vault stack is structured around extension points. Each point in the lifecycle where different products need different behavior is exposed as a swappable module. 

• The core contracts handle the invariants: correct accounting, hub-and-spoke messaging, and access controls 
• Modules handle the policies: who can transfer, how requests are processed, how pricing works.

Here are some of the key extension points that illustrate the design philosophy.

Share tokens and transfer hooks

Every share token calls out to a transfer hook on every ERC-20 transfer. The hook decides whether the transfer is allowed based on the sender, receiver, and the type of operation (deposit, redemption, secondary transfer, cross-chain move).

The protocol ships multiple hook implementations covering the spectrum from fully restricted (memberlist required for all operations) to freely transferable (anyone can hold and transfer in secondary markets) to freeze-only (no memberlist, just a compliance kill switch). Builders select the model that fits their product, or write their own. The interface is a single function. Hooks are upgradeable without redeploying the token contract.

Sync vs async vaults

Not every asset needs asynchronous settlement. A stablecoin wrapper or a liquid onchain asset can handle instant deposits. An illiquid credit fund cannot.

The stack supports both through separate vault types:

• An async vault implements the full ERC-7540 request/claim lifecycle for both deposits and redemptions. 
• A sync-deposit vault offers instant ERC-4626 deposits at the current price while keeping redemptions asynchronous, because the underlying assets may not be instantly liquidatable. 

Each vault type delegates to its own request manager, so the settlement model is determined by configuration, not by forking the codebase.

Batching on any cadence

Async vaults process requests in epochs. The epoch-based request manager on the hub accumulates deposit and redemption requests and fulfills them in batches, recording prices at fulfillment so investors receive their pro-rata allocation.

The batching cadence is not hardcoded. The fund manager controls when epochs close. A treasury fund might run epochs daily. A credit fund might batch weekly. A fund with complex NAV calculations might process monthly. The contracts enforce sequential processing but leave the timing entirely to the manager. Different share classes and deposit assets within the same pool can even run on independent epoch cycles.

Hub managers for pricing and NAV

Any contract that implements the NAV hook interface can be set as a pool's hub price manager. This is where NAV calculation, share pricing, and tranche allocation logic lives.

The protocol ships a simple price manager for single-tranche pools that divides total NAV by total issuance. But the interface is open. A builder can deploy a custom hub manager that implements waterfall logic for senior/junior tranches, applies a fee accrual model, or prices shares based on any onchain or oracle-fed data. The share class manager supports multiple share classes per pool, each with independent issuance tracking and pricing. The hub manager decides how to distribute value across them.

This means a senior/junior structure, a multi-currency fund, or an entirely novel pricing model all plug into the same core. The accounting and settlement are handled. The pricing logic is yours.

Balance sheet managers for allocation

On the spoke side, any contract can be set as a balance sheet manager. This is the extension point for how a pool's assets are actually held, moved, and allocated.

A balance sheet manager handles deposits into the pool's reserves, withdrawals to fund redemptions, and any interaction with external protocols or custody arrangements. The default implementation covers standard reserve management. But a builder can deploy a custom balance sheet manager that routes deposits into a DeFi lending protocol, manages on/off-ramp flows to fiat, or implements a multi-strategy allocation engine. The core enforces correct accounting for whatever the manager does. The allocation logic is entirely pluggable.

Cross-chain adapters

The same pattern applies to cross-chain messaging. The gateway routes messages through adapters, and any contract that implements the adapter interface can be used. The protocol ships adapters for LayerZero, Wormhole, Axelar, and Chainlink CCIP. Pool deployers select which providers to use, and can add new ones as the interoperability landscape evolves.

This matters because no single messaging provider dominates, and the competitive landscape shifts fast. A pool that launched on LayerZero can add Chainlink CCIP without redeployment, migration, or any change to its accounting. If a provider suffers an outage or a security incident, the pool can route through an alternative. The adapter interface also means pools are not locked into the economics of a single bridge: as new providers launch with lower fees or faster finality, they become available to every pool through a single adapter deployment.

The ideal platform for AI agents

This modularity makes Centrifuge's vault stack a natural platform for AI-driven development.

An agent building onchain doesn't need to reinvent accounting, settlement, or cross-chain infrastructure. It needs clean abstractions with well-defined interfaces and constrained blast radius. The programmable vault stack provides exactly that: deploy a vault by selecting modules, configuring parameters, and composing existing building blocks. The agent never touches the security-critical core.

This is the difference between asking an AI to "write a vault from scratch" (high risk, large attack surface, requires expert review) and asking it to "configure a vault with weekly batching, a management fee hook, and freely transferable share tokens" (bounded, auditable, safe). The first is a research project. The second is a product deployment.

As AI agents become more capable at onchain development, the platforms that win will be the ones with the best separation between infrastructure and configuration. Secure, audited, immutable infrastructure on the bottom. 

Beyond contracts: SDK, API, and management app

The onchain protocol is the foundation, but builders don't have to interact with contracts directly. Centrifuge provides a full developer stack on top.

The Centrifuge SDK gives developers a typed, high-level interface for querying pool data, submitting investment requests, and managing vault operations from any JavaScript/TypeScript environment. The Centrifuge API exposes the same data through a public GraphQL endpoint for teams that need server-side integration or analytics without running their own indexer.

For fund managers and operations teams, the Centrifuge Management App provides a purpose-built interface for vault management and capital allocation: pool configuration, epoch processing, NAV updates, role-based permissions, and cross-chain deployment. No reliance on the core development team to operate. No CLI required.

Protocol, SDK, API, and management app form a complete stack. A team that would otherwise spend a year building vault infrastructure, cross-chain messaging, accounting, and an operations dashboard can go to production in weeks by building on what already exists.

‍