Skip to content

Tokenized Vault Infrastructure

In short

Tokenized vault infrastructure (ERC-4626/7540) for funds and RWA platforms: async subscription/redemption, role-based governance, and sovereign deployment you own and control.

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 is the operating layer most teams that "need a vault" actually need, governance, approvals, transfer restrictions, async subscription and redemption, NAV settlement, reporting, and integrations.

Building that stack in-house typically takes 6-9 months and a dedicated 4-6 engineer team. Public, shared-protocol vaults, curated Morpho vaults among them, are useful yield destinations, but you don't own the contracts, the governance keys, or the upgrade authority. Protofire closes that gap with VaultOS: an ERC-4626/7540 vault core, a policy engine, and the operational rails around it, productized so the vault contracts and the governance root belong to you.

We're 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, and we've shipped on-chain finance infrastructure before, so the tokenized vault infrastructure we hand you, productized as VaultOS, is one we run, 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

Safe Governance

Protofire's Safe Guardian standing integrates Safe multisig at the governance root for institutional approvals and controlled upgrade authority.
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

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 root · no shared-protocol dependency · a control plane your risk and compliance teams can govern.

02

How a VaultOS deployment works

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.

Foundation build (weeks 1-4): Vault core, control-plane hooks, reporting and workflow setup, and the first adapter or destination integrations.

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.

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.

03

What clients deploy VaultOS for

Post-issuance distribution control for tokenized securities (P1)
Async subscription & redemption for tokenized funds (ERC-7540, P2)
Continuous transfer restrictions & KYC/jurisdiction gating (P3)
Vault governance & seven-role separation (Valuation Provider, Risk Guardian) (P4)
Sovereign, client-owned vault deployment (P5)
Async credit-pool operations with tranching and pool governance
Governed treasury & POL vaults with approvals and reporting
White-label vault layer for RWA infrastructure platforms
Manager / curator enablement: proposal flows, rebalancing, operator console
04

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 seven-role 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.

05

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; 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
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, 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 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, and the vault settles it later 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 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, and a seven-role governance model 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, sovereign 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.
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. A focused MVP can be stood up in about 30 days, while a full pilot through control plane, async settlement, valuation workflow, and handover runs 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 Luis Medeiros, Field CTO at Protofire. Last reviewed: June 2026.

Book a call with Alejandro Losa

Schedule a call with our Business Development Manager to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved