Skip to content

Tokenized Vault Infrastructure

In short

Tokenized vault infrastructure (ERC-4626/7540) for funds, RWA platforms, and treasuries: async subscription and redemption, role-based governance, a six-mechanism exit engine, and sovereign deployment you own and control. Productized by Protofire as VaultOS.

250+
projects delivered since 2016
$2B+
secured across 120+ networks (Safe Guardian)
60+
networks deployed on
1M+
developers rely on Solhint
Trusted by teams building on-chain

Tokenized vault infrastructure is the layer that lets your organization deploy, own, and govern an on-chain vault instead of renting a shared protocol. A tokenized vault is the on-chain account that holds capital, issues shares to depositors, and routes that capital under rules; the infrastructure around it, governance, approvals, transfer restrictions, async subscription and redemption, NAV settlement, reporting, and integrations, is the operating layer most teams that "need a vault" actually need.

Protofire productizes that layer as VaultOS, a neutral vault operating system for active managers and their LPs: an ERC-4626/7540 vault core, a per-role policy engine, a six-mechanism exit engine, and the operational rails around it, deployed so the vault contracts and the governance root belong to you. It exists because most tokenized assets today are still wrapper-only, unable to compose with DeFi, TradFi, or each other.

We are the engineering team behind 250+ shipped projects since 2016, an official Safe Guardian, and the maintainer of Solhint, the Solidity linter used by 1M+ developers, so the tokenized vault infrastructure we hand you, productized as VaultOS, is one we run in production, not a reference architecture.

The VaultOS infrastructure stack, from vault core to operator tooling

Each layer is client-owned, not hosted behind a shared protocol or third-party governance key.

01

Vault Core (ERC-4626/7540)

Standards-based on-chain vault that holds capital, issues transferable shares, and routes assets under defined rules with interoperable accounting.
02

Policy Engine (P1-P3)

Post-issuance distribution control, async subscription and redemption (ERC-7540), and continuous transfer restrictions enforced at the vault layer.
03

Seven-Role Governance (P4)

Vault Admin, Valuation Provider, and Risk Guardian roles replace a single owner or multisig with bounded, segregated authority over approvals and NAV settlement.
04

Exit Engine

Six switchable exit mechanisms, from a fast pool to a coverage overlay, matched to the asset's liquidity and the investor's type.
05

Sovereign Deployment (P5)

Client-owned deployment rails with optional custody/MPC connectors: the vault contracts and governance keys belong to your organization.
06

Manager / Curator Tooling

Operator console, proposal flows, rebalancing workflows, and audit reporting for vault managers and curators.
01

Why the tokenized economy is stuck under wrappers

Most tokenized assets today are wrapper-only tokens: a claim wrapped in an ERC-20, with no native way to enforce eligibility after issuance, settle against NAV, or compose with lending, staking, or other assets. Pantera Capital's State of Tokenization Q1 2026 puts the tokenized market at about USD 320.6B and finds that 77.6% of the assets it tracks (by count) sit in the lowest wrapper tier: blockchain wrappers around traditional infrastructure rather than native on-chain instruments that compose with DeFi, TradFi, or each other. Stablecoins are the standout exception; most other tokenized assets, the RWAs, funds, and credit VaultOS is built for, are still wrappers (source: Pantera Capital).

The blocker is not demand, it is engineering: building a production vault stack with async flows, a policy engine, role-separated governance, and institutional exits takes months of senior smart-contract work and at least two audit passes. VaultOS exists to collapse that build, so an active manager can turn tokenized real-world assets and DeFi yield into an institutional product their LPs can plug into, in weeks rather than quarters, on contracts the manager owns.

02

What we build: tokenized vault infrastructure, productized as VaultOS

VaultOS is deployed for you and owned by you: the vault contracts, the policy configuration, and the governance root sit inside your organization's control, not behind a third-party protocol, custodian, or external operator. That is the difference between a public vault and private vault infrastructure, with a shared protocol you route capital into someone else's contracts; with VaultOS you launch governed vault products on rails you control, with a defined upgrade path.

Sovereign deployment (problem P5 in our framework) is a hard requirement for treasuries and institutions that cannot make their capital operations depend on an external party's keys or roadmap. Benefits: you own the contracts and the governance keys · no shared-protocol dependency · a control plane your risk and compliance teams can govern.

03

The VaultOS modules: five gaps you close after issuance

P1 · Post-Issuance Distribution Control

A Distribution Controller and an Investor Registry enforce who can hold the asset, and under what conditions, after mint.

P2 · Async Subscription and Redemption

An Async Request Manager and a NAV Settlement Engine run the ERC-7540 request and settle flow.

P3 · Transfer Restrictions and Compliance

A Transfer Restriction Module with KYC and jurisdiction gating enforces investor eligibility continuously at the vault layer, not at issuance alone.

P4 · Vault Governance and Role Separation

A seven-role permission model (Vault Admin, Curator/Strategist, Valuation Provider, Whitelist/Compliance Manager, Risk Guardian, Operations Manager, and Auditor/Regulator Viewer) replaces a single owner or multisig with bounded, segregated roles.

P5 · Sovereign Deployment

Client-owned deployment rails, with optional custody/MPC connectors and shared-governance variants.

04

Five properties no off-the-shelf vault delivers

01

Client-owned EVM contracts

Your institution holds the upgrade keys and the governance root. No tenant slot on a shared protocol, and no external party's roadmap sitting inside your capital operations.

02

Multi-vertical composability

Lending, tokenized RWAs, staking and restaking, liquidity provision, and structured positions in a single vault, instead of a separate rebuild per vertical.

03

Per-role policy engine

A human-readable, versioned, approval-gated policy layer your risk and compliance teams can read directly, so engineering does not translate every rule by hand.

04

ERC-7540 native

Asynchronous capital calls, NAV windows, and queued redemptions as first-class flows, built for fund cadence rather than instant swaps.

05

AI-augmented operations

Optional AI for strategy execution, anomaly detection, and reporting, always bounded by the policy engine and never above it.

05

The Exit Engine: six ways to exit or unlock liquidity

Every institutional vault needs an exit, and no single mechanism fits every asset. VaultOS ships six and switches on the one the asset and the investor actually need, rather than a one-size-fits-all pool. Long-dated assets need a way out; instantly redeemable ones need downside protection. The underlying's liquidity, price behavior, and investor type decide which exit applies.

Liquidity of the underlying
What the investor needs
Pick an asset profile; the engine lights the exits that fit.
S1

Fast Exit Pool

Out now at a set discount (for example, minus 5%), funded by paid risk capital rather than the issuer. Instant, with cold-start risk.

S2

Reverse-Dutch auction

List a position; the discount starts at 0% and rises until a buyer fills. Price is discovered, with no standing pool to fund.

S3

NAV redemption cap

Withdraw at NAV under a public, on-chain rule (for example, 5% per quarter), enforced in the contract. Fair and transparent, though not instant.

S4

Composability wrapper

Wrap the position to a standard receipt and route it to external venues, or borrow against it instead of selling.

S5

Eligibility-gated OTC

A KYC-gated request-for-quote desk for block trades; settlement validates the whitelist privately on-chain.

S6

Coverage overlay

Buyers stand ready to purchase only on a trigger such as a default or depeg, at a set discount, earning a premium for the cover. Insurance-like.

06

How a VaultOS deployment works

1

Discovery & architecture workshop

We select a deployment profile, the vault model (ERC-4626 vs ERC-4626 + ERC-7540), policy and governance requirements, and the integration map. Deliverable: a scoped architecture and deployment plan.
2

Foundation build (weeks 1-4)

Vault core, control-plane hooks, reporting and workflow setup, and the first adapter or destination integrations.
3

Control plane v1 (weeks 5-8)

Eligibility and transfer rules, the expanded seven-role model, the operator console, audit preparation, and ERC-7540 request flows defined.
4

Pilot deployment & handover (weeks 9-12)

Async settlement engine, the valuation-provider workflow, a limited-capital pilot, operational playbooks, and handover to your team. Custody/MPC connectors, shared-governance variants, and jurisdiction templates follow post-pilot.
07

Who builds on VaultOS: six active-manager profiles

Each profile brings a different vault shape. VaultOS supports all six without forcing one rigid model, and each maps to a primary problem set in the module framework.

Stablecoin issuers

Composable backing vaults with policy-gated mint and redeem, so reserves stay productive, eligible, and auditable.

Primary modules
P1P3
08

Build in-house vs run on VaultOS

Same product, a fraction of the time and cost, with engineering rigor inherited from a decade of production deployments. The in-house figures assume senior smart-contract talent, at least two audit passes, and integration work per vertical, and exclude ongoing maintenance headcount.

Build in-house
Run on VaultOS
Time to a live product
Months of build cycles plus at least two audit passes
Weeks, on infrastructure already in production
Engineering and audit cost
USD 300K to 500K and up per product, before ongoing maintenance
An audited core, reused and scoped per deployment
Multi-vertical from day one
Each vertical is a separate rebuild
Lending, RWA, staking, and structured positions compose natively
Time to a second product
About the same cost as the first
Days, on the same substrate
Sovereign upgrade authority
Negotiated per stack against someone else's protocol
Default: the contracts and the governance root are yours
09

What clients deploy VaultOS for

Post-issuance distribution control for tokenized securities (P1)
Async subscription and redemption for tokenized funds (ERC-7540, P2)
Continuous transfer restrictions and KYC/jurisdiction gating (P3)
Vault governance and seven-role separation (Valuation Provider, Risk Guardian) (P4)
Sovereign, client-owned vault deployment (P5)
A six-mechanism exit engine matched to the asset and the investor
Async credit-pool operations with tranching and pool governance
Governed treasury and POL vaults with approvals and reporting
Own-brand, curated yield vaults for fintechs and asset managers
White-label vault layer for RWA infrastructure platforms
Manager and curator enablement: proposal flows, rebalancing, operator console
10

A first-hand engineering narrative

In a treasury and protocol-owned-liquidity pilot with AP3X, capital operations were fragmented across scripts, spreadsheets, and protocol-by-protocol decisions, workable, but impossible to govern, observe, or audit. We followed the deployment sequence above: discovery fixed the profile and policy model, we stood up the ERC-4626 vault core with policy hooks, layered the control plane and role-separated governance model, then ran a limited-capital pilot with monitoring and rebalancing before handover.

The outcome was a single governed, observable vault replacing the script-and-spreadsheet workflow with governed, observable, auditable capital operations.

11

Design partners

VaultOS has been shaped with design partners across its core audiences: treasury and protocol-owned-liquidity teams, RWA and tokenization infrastructure platforms, and fund/product platforms. These engagements validated the core model: a sovereign, client-owned control plane; ERC-7540 async subscription/redemption flows; role-separated vault governance; a switchable exit engine; and privacy features for allocator-side vault operations that platforms intentionally don't build themselves. Together they span the buyer profiles VaultOS is built for, tokenized funds and securities, credit, treasury, and RWA-OS platforms.

Protofire is an engineering-led blockchain development firm, 250+ projects across 60+ networks and 95+ protocols since 2016, an official Safe Guardian (Safe secures $2B+ across 120+ EVM networks), a Chainlink core contributor, and maintainer of Solhint. For on-chain finance we've shipped production systems including the Swarm Markets BaFin-regulated tokenized-securities DEX, so VaultOS comes from a team that runs vault and tokenization infrastructure in production, not a slideware reference design.

“You own the contracts and the governance root, not a third-party protocol.”

Vault Infrastructure: Shared Protocol vs. Sovereign Deployment

Shared public-vault protocolVaultOS
Contract ownership & governance keysProtocol holds governance; your vault policies depend on protocol upgradesYour organization owns vault contracts, governance keys, and upgrade authority
Async subscription & redemption (ERC-7540)Not supported; synchronous deposits/withdrawals onlyERC-7540 async request/settle flows with separate Valuation Provider and Risk Guardian roles
Institutional exitsNone, or a single shared redemption poolSix-mechanism exit engine: fast pool, reverse-Dutch, NAV cap, wrapper, gated OTC, coverage overlay
Multi-vertical composabilityPer-vertical, often a separate deployment eachLending, RWA, staking, and structured positions in one vault
Role-based access controlSingle unified model across all vaultsSeven-role permission model (Vault Admin, Valuation Provider, Risk Guardian, etc.) for segregated authority
Policy engine & transfer restrictionsFixed rules; limited customization per vaultModular policy engine; custom transfer rules, KYC/jurisdiction gating, continuous eligibility enforcement

FAQ

What is VaultOS?
VaultOS is Protofire's tokenized and private vault infrastructure: an ERC-4626 and ERC-7540 vault core, a policy engine, a six-mechanism exit engine, and the operational rails around it, governance, approvals, transfer restrictions, async subscription and redemption, NAV settlement, reporting, and integrations, that you deploy, own, and govern. Unlike a shared public-vault protocol, the vault contracts and the governance root belong to your organization, not a third-party protocol, custodian, or external operator. It ships as a module set mapped to the five operational gaps RWA and tokenization platforms hit after issuance (P1-P5): post-issuance distribution control, async subscription and redemption, transfer restrictions and compliance, vault governance with a seven-role permission model, and sovereign deployment. You turn modules on as the product matures instead of rebuilding. Protofire deploys VaultOS for treasuries, tokenized funds, credit marketplaces, securities issuers, and RWA platforms that cannot make capital operations depend on an external party's keys or roadmap.
What is a neutral vault OS for active managers?
A neutral vault operating system is infrastructure an active manager uses to run vault products without being locked into one protocol, one vertical, or one counterparty's governance. "Neutral" means the manager owns the contracts and the governance root and can route to any approved yield source or venue, rather than operating as a tenant inside a shared protocol that sets the rules. "For active managers" means the system is built for teams that make allocation decisions, stablecoin issuers, treasury and RWA issuers, private credit originators, restaking protocols, lending curators, and structured-product issuers, and need a way to turn tokenized real-world assets and DeFi yield into an institutional product their LPs can plug into. VaultOS is Protofire's neutral vault OS: an ERC-4626/7540 core, a per-role policy engine, a six-mechanism exit engine, and client-owned deployment, so the manager keeps the product, the economics, and the keys.
What is a tokenized vault?
A tokenized vault is an on-chain smart contract that holds capital, issues transferable shares to depositors that represent their claim on the assets, and deploys that capital under defined rules. ERC-4626 is the standard that makes vault deposits, redemptions, and share accounting interoperable across DeFi, it defines how a vault accepts a deposit, issues shares, and converts between assets and shares. The vault itself is only part of what most teams need: around it sits an operating layer of governance, approvals, transfer restrictions, async subscription and redemption, NAV settlement, reporting, and integrations. That distinction matters because a public, shared-protocol vault gives you a destination to route capital, but you do not own its contracts or governance keys. Tokenized vault infrastructure, what Protofire productizes as VaultOS, is the layer that lets your organization deploy, own, and govern its own vault rather than rent one.
What's the difference between ERC-4626 and ERC-7540?
ERC-4626 is the tokenized-vault standard for synchronous deposits and withdrawals, you deposit and receive shares in the same transaction, and it standardizes how a vault accepts deposits, issues shares, and converts between assets and shares. ERC-7540 is the asynchronous extension: instead of an immediate swap, an investor submits a deposit or redemption request that the vault settles later, in a separate transaction. ERC-7540 defines that request and settle flow and is price-agnostic; in VaultOS each request settles against a net asset value struck by a separate Valuation Provider role, with a policy gate controlling who can transact and when. Async flows are what tokenized money-market funds, treasury funds, and credit pools require, because NAV is struck periodically and redemptions are queued rather than instant, the request, settle, NAV-gate lifecycle that public synchronous vaults and manual scripts cannot deliver at institutional quality. VaultOS supports both: an ERC-4626-compatible core, with ERC-7540 added for institutional products where settlement is not instant.
How does VaultOS handle investor exits and redemptions?
VaultOS ships a six-mechanism exit engine and switches on the one the asset and the investor actually need, rather than forcing a single redemption model. The mechanisms are: a Fast Exit Pool (out now at a set discount, funded by paid risk capital, not the issuer); a Reverse-Dutch auction (the discount starts at zero and rises until a buyer fills, so price is discovered with no standing pool); a NAV redemption cap (withdraw at NAV under a public on-chain rule such as 5% per quarter); a composability wrapper (wrap to a standard receipt and route to external venues, or borrow against the position instead of selling); an eligibility-gated OTC desk (a KYC-gated request-for-quote flow for block trades, with the whitelist validated privately on-chain); and a coverage overlay (buyers who stand ready to purchase only on a trigger such as a default or depeg, earning a premium).

Long-dated assets need a way out; instantly redeemable ones need downside protection. The underlying's liquidity, price behavior, and investor type decide which exit applies.
Can one VaultOS vault support lending, RWA, staking, and perps at once?
Yes. Multi-vertical composability is a core property of VaultOS: a single vault can hold and route across lending markets, tokenized real-world assets, staking and restaking positions, liquidity provision, and structured or perp exposure, instead of forcing a separate rebuild per vertical. Each position is governed by the same per-role policy engine, so eligibility, approvals, and risk limits apply consistently across whatever the vault composes into. This matters because most tokenized products today are wrapper-only and cannot compose with each other; a manager who wants a blended strategy would otherwise deploy and maintain several disconnected vaults. On VaultOS the manager configures the verticals the product needs, keeps one governance root and one audit trail, and turns additional modules on as the product matures rather than rebuilding.
How is VaultOS different from Morpho vaults or other public vaults?
Curated public vaults such as Morpho vaults give you a useful destination to route capital, but the protocol owns the vault contracts, the governance keys, and the upgrade authority, not you. VaultOS is private, client-owned vault infrastructure: the vault contracts, the policy configuration, and the governance root sit inside your organization's control, with a defined upgrade path, and you add a policy engine, continuous transfer restrictions, ERC-7540 async flows, a seven-role governance model, and a six-mechanism exit engine on top. You can still route to public vaults as approved destinations. The distinction matters most for treasuries and institutions that cannot make their capital operations depend on an external party's keys or roadmap, client-owned deployment (problem P5 in our module framework) is a hard requirement for them. With a shared protocol you route capital into someone else's contracts; with VaultOS you launch governed vault products on rails you control.
Can a tokenized fund or custodian use VaultOS to enforce investor eligibility and NAV-based redemptions?
Yes. VaultOS enforces investor eligibility, KYC, and jurisdiction rules continuously at the vault layer, not at mint alone, through a Distribution Controller, an Investor Registry, and a Transfer Restriction Module, so eligibility stays authoritative after the asset is issued. For entry and exit it runs ERC-7540 async subscription and redemption with NAV settlement handled by a separate Valuation Provider role and overseen by a Risk Guardian, replacing a single owner or multisig with bounded, segregated roles. That seven-role permission model, including Vault Admin, Valuation Provider, and Risk Guardian, is the role separation institutional fund operations require, and it lets an allocator's risk and compliance teams see exactly who can hold the asset, how redemptions are controlled, and who strikes NAV. These capabilities map to the P1-P4 modules: distribution control, async flows, transfer restrictions, and governance role separation.
How long does a VaultOS deployment take?
A focused MVP can be stood up in about 30 days; a full pilot typically runs about 12 weeks. The pilot follows a defined sequence: a discovery and architecture workshop fixes the deployment profile, the vault model, and the policy and governance requirements; a foundation build (weeks 1-4) stands up the vault core, control-plane hooks, reporting, and the first adapter integrations; control plane v1 (weeks 5-8) adds eligibility and transfer rules, the expanded seven-role model, the operator console, and ERC-7540 request flows; and pilot deployment and handover (weeks 9-12) brings the async settlement engine and the valuation-provider workflow online, runs a limited-capital pilot, and hands operational playbooks to your team. Custody/MPC connectors, shared-governance variants, and jurisdiction templates follow post-pilot. We confirm the exact timeline against your deployment profile in the discovery workshop.
Can a fintech or asset manager launch its own branded yield vault?
Yes, that is a core use case. VaultOS is a client-owned vault core, so a fintech, asset manager, or B2B2C platform can launch its own branded, curated vault, its name, its fee, its distribution, with Protofire building and operating the infrastructure underneath. You choose the strategy the vault routes into, we build the ERC-4626 or ERC-7540 core, the policy and control plane, eligibility and transfer rules, and the reporting, and you keep the customer relationship and the economics. This is the difference between depositing into a public vault someone else curates and offering your own: your holders see your product, and the yield, fees, and governance are yours. For fintechs launching a branded vault alongside earn or lending products, see blockchain infrastructure for fintechs.
How much does VaultOS cost?
Protofire scopes every VaultOS engagement to your deployment profile and compliance requirements rather than a fixed package, so the cost is sized in the discovery and architecture workshop before any build starts. The variables that move it are the vault model (ERC-4626 alone, or ERC-4626 plus ERC-7540 async flows), how many of the P1-P5 modules you turn on, post-issuance distribution control, async subscription and redemption, transfer restrictions, governance role separation, and sovereign deployment, your compliance and jurisdiction scope, and the integrations you need. For context, building an equivalent vault stack in-house typically runs USD 300K to 500K and up per product in senior engineering and multiple audits, before ongoing maintenance; VaultOS reuses an audited core, so a focused MVP can be stood up in about 30 days and a full pilot in about 12 weeks. You receive a fixed scope and estimate from the workshop, so there are no open-ended costs once the build begins.

Reviewed by Cristian Malfesi, Field CTO at Protofire. Last reviewed: July 2026.

Book a call with Alejandro Losa

Schedule a call with our Web3 Solution Architect to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved

Message us on Telegram