In this post, we describe the key technical features and engineering design decisions that power strataOS, our next generation onchain asset management platform.
About us: RockSolid has built and operated vault infrastructure since September 2025, with $25M+ of AUM for partners including Rocket Pool, MAVAN (a Bitmine company) and MegaETH, with zero losses or exploits since inception. That experience shapes strataOS, our onchain asset management platform for institutions.
–
“The institutions are coming” has been a catch-cry for years now, and while we see tokenized T-Bills, equities and private credit, it's a tiny fraction of the logic and the capital in the traditional financial system: roughly $39 billion of tokenized real-world assets circulate on public chains, compared to a market of tens of trillions in regulated funds alone.
Funds in particular are a huge part of traditional finance that have only just started to move onchain. Some funds are simply tokenized representations of their “paper” equivalent. Some are indeed natively issued onchain, but even Blackrock’s BUIDL, which is issued natively onchain, still runs the fund itself offchain: subscriptions, redemptions and valuation are handled by BlackRock as investment manager, BNY Mellon as custodian and fund administrator, and Securitize as transfer agent
There is much work to be done before all assets are issued natively onchain. At RockSolid, we believe one barrier to providing truly onchain native fund management has been the design choices of DeFi protocols and the challenges and limitations of Solidity and the EVM. Many DeFi protocols have eschewed rich functionality for simplicity and auditability; understandable of course, but this has very real limits to the types of use cases that can be expressed onchain.
The sophistication of the fund management industry requires more logic that can be safely expressed onchain today, given current approaches. We built strataOS to be the onchain asset management platform of today, and the future. That meant it must not only handle any type of DeFi or TradFi asset, but also be extensible and upgradable, without fear of hitting size limits. Below, we describe some of the engineering choices we made to ensure strataOS will be the default onchain asset management platform of the future.
Existing patterns
We saw multiple approaches for DeFi protocols to manage complexity on chain:
Single contracts under 24kb
It’s impressive how much logic creative solidity engineers can pack into a single contract. However, even with satellite or ‘helper’ contracts, even defining 100s of methods on a contract will exhaust 24kb, making the pattern infeasible for feature-rich platforms.
Diamond pattern
The diamond pattern (EIP-2535) puts some structure around how to build a modular smart contract system. A single proxy, the "diamond", holds all the state and a table mapping each function selector to a "facet" contract that implements it. Facets can be added, replaced or removed through a single admin function: diamondCut, so there's no practical limit on total code size. However, this pattern has some very sharp edges that make it difficult to audit and reason about.
The first is how facets talk to each other. When the deposit facet needs logic that lives in the settlement facet, a common approach is for it to call back into the diamond, e.g. this.settle(), which routes the call to the settlement facet. That facet may in turn call back in again to reach the fees facet. One user call ends up passing through the proxy three times, and on every re-entry msg.sender becomes the diamond itself. Access checks and reentrancy guards have to account for the system calling itself, and the true call graph only exists at runtime. You can't read it or reason about it from any single file.
The second is that the routing table is mutable. The admin diamondCut() function can re-point any selector to new code at any time, one function at a time. The call graph an auditor traced may not be the one that's live today, and after a few upgrades it gets hard to say exactly which version of what code a given call will run.
Figure 1) Diamond proxy call patterns
Hybrid Approaches
The Euler whitepaper names their pattern “Static Modules” and states the goal:
For code organisation purposes, and also to comfortably stay below code size limits at full optimisation levels, the component implementation contracts are organised into modules. The primary entry point contract EVault serves as a dispatcher that determines which module should be invoked.
We believe this is an improvement on the diamond pattern, but it still has a few rough edges. The routing is static: module addresses are fixed in the vault's code, so the call graph an auditor reviews is the one that runs. Modules don't call each other either; shared logic is compiled into each one. But it still has the following limitations:
-
Logic lives in two places. Some functions are implemented directly in the EVault dispatcher for gas efficiency, while the rest are delegated to modules. To understand a call, you first have to work out which kind it is.
-
View functions call back into the vault. Solidity won't let a view function delegatecall, so EVK has the vault staticcall itself, which then delegatecalls the module. It's read-only and contained in one place, but it's still a self-call.
-
Modules are tied to their deployment. Modules carry configuration fixed in their bytecode, and the docs recommend deploying fresh modules for every vault.
The RockSolid Approach
We took static modules as our starting point and pushed each idea further.
Static dispatcher: Every vault is a proxy that delegates to a dispatcher, and the dispatcher does one thing: it looks up the function selector in a routing table compiled into its code and delegatecalls the module that owns it. It contains no business logic, and the table can't change after deployment. It also implements the read-only "loupe" functions from the diamond standard, so block explorers can still list every method on the vault. Nothing can be cut or re-routed.
Single-path call graph: Every call follows the same path: caller, vault, dispatcher, one module. That module completes the whole operation. Modules never call each other, and nothing calls back into the vault, not even for views. We don't rely on convention for this; it's checked three ways:
- static analysis of the source, which fails on any self-call or call to another module
- opcode counts on the deployed bytecode: the dispatcher contains exactly one DELEGATECALL, and modules contain none
- a test that records every call during a full set of vault operations and fails on any re-entry into the vault
Shared logic compiled in: NAV, fees, queue and access logic live in internal libraries that are compiled into each module that needs them. A module never has to reach across to another to do its job, which is what keeps the call graph to a single path.
Upgradable releases: Modules hold no configuration of their own; it all lives in the vault's storage. One set of modules serves every vault. An upgrade is a new release: changed modules are deployed, unchanged ones are reused at their existing addresses.
Timelocked upgrades: Moving to a new release is a single beacon switch that every vault follows, and that switch is timelocked in the contract itself. During the delay, anyone can check the new dispatcher against the published source. An independent guardian can cancel it.
Figure 2) RockSolid call patterns and restrictions
The result is code paths that are easy to follow and audit, with no 24kb ceiling on the vault as a whole. That comes at a modest cost: one extra delegatecall hop per call, shared library code duplicated across modules, and a 24kb limit on each module, which we handle by adding a new module in a new release.
Summary
Bringing traditional finance onchain, especially fund management, will require significant amounts of logic and frequent iterations. System designs that limit functionality to fit under size constraints cannot be sufficiently expressive. Designs that embrace modules, without imposing sufficient restrictions on call-graphs are too difficult to reason about and will be more susceptible to exploits. The RockSolid approach extends the best of breed smart contract design to provide extensibility, upgradability, auditability and the ability to ship complex logic, to help bring more of traditional finance onchain.
—