A security stack for RWA vaults: from assets to smart contracts

Most conversations about RWA security still collapse everything into one vague question: “is this protocol safe?”. For institutional capital, that is not how risk is evaluated. Serious allocators think in layers: what is the legal structure under the token, who holds the assets, who curates the risk, and what exactly can the smart contract do or not do.

A RWA vault is only as strong as its weakest layer. A perfect on-chain implementation sitting on top of a sloppy legal wrapper is not “safe DeFi” – it is just an efficient interface to a weak off-chain promise. The opposite is also true: a well-structured asset pool can be ruined by upgradeable contracts, opaque permissions, or poorly designed vault logic.

Layer 1: the real-world asset and legal wrapper

The bottom of the stack is the actual asset: credit, receivables, Treasuries, real estate, or something else. Here the questions are boring and extremely important: who owns the asset, how is it held, what happens in default, and what rights does the token actually represent.

Institutional frameworks look for clear SPVs, enforceable contracts, and well-defined claim hierarchies. In a tranched structure, that means senior and junior token holders must map cleanly to real-world priority in cash flows and liquidation. If a vault promises “first-loss protection” on-chain but the legal wrapper does not recognize that structure, the senior tranche is marketing, not risk engineering.

Layer 2: custody, treasury operations, and key management

Above the asset, there is custody and treasury infrastructure. Who controls the private keys that can move RWA tokens or claim underlying assets? How are redemptions handled? Are keys held by institutional custodians, multi-sigs, MPC wallets, or a single operator?

For an RWA vault, this is where “institutional-grade” either starts to mean something or falls apart. A protocol can outsource custody to licensed providers, use multi-signature setups for treasury movements, and clearly separate operational keys (for day-to-day flows) from governance keys (for parameter changes). The important part is that this layer is documented and auditable – not improvised around a single hot wallet.

Layer 3: risk curation and strategy

Next comes risk curation: which assets enter the vault, under what parameters, and how often those assumptions are reviewed. In DeFi, this role is often implicit. For RWA, it has to be explicit. Someone has to decide which originators are trusted, what maximum exposure per asset or borrower is allowed, and how concentration risk is handled over time.

Some platforms formalize this as an investment committee. Others offer “curated vaults” where a professional manager defines the portfolio and risk limits. For a protocol like STRATA, the vault is designed to separate this layer from the pure mechanics: risk curation decides what can flow into the vault, the vault logic decides how that risk is sliced between senior and junior tranches.

Layer 4: identity, eligibility, and access control

Identity and eligibility sit above risk curation, but they are tightly coupled. It is not enough to have a safe asset pool and good strategy; the protocol also needs to ensure the right participants end up in the right tranches. This is where self-sovereign identity, verifiable credentials, and Authorization PDAs enter the picture.

Instead of static whitelists, STRATA uses short-lived authorizations derived from SSI checks. That means access rules – who can touch senior, who is allowed into junior, which jurisdictions are permitted – are enforced on-chain, but remain anchored in real-world KYC and suitability processes. This layer protects both investors and the protocol from mis-selling and regulatory blind spots.

Layer 5: the vault program itself

At the top of the stack sits the on-chain vault code. This is the part that looks most like “DeFi”, and it is where Solana-specific engineering matters: PDAs, CPI patterns, token accounting, and gas/compute constraints. A vault program must define:

• How deposits and redemptions are processed;
• How shares and assets are accounted for;
• How the tranche waterfall works in normal operation and in loss scenarios;
• Which parameters, if any, can be changed, and by whom.

For STRATA, the vault mechanics – especially the senior/junior waterfall – are immutable. The program encodes exactly how losses are allocated, how buffers work, and which operations require valid Authorization PDAs. That makes this layer predictable: auditors, integrators, and risk teams can reason about behavior under stress without guessing what an upgradeable proxy might secretly do later.

Why a stack view matters for builders

Thinking in layers forces RWA builders to stop treating “smart contract audit” as the only line item under “security”. A clean audit on a vault program is necessary, but not sufficient. You also need legal enforceability, robust custody, transparent risk curation, and identity-aware access control.

Designing STRATA’s vault as just one layer in a larger security stack is intentional. The goal is not to pretend that code can fix everything off-chain. It is to make sure the on-chain pieces – vault logic, identity enforcement, and PDAs – are strong enough that they do not become the weak link in an otherwise institutional-grade RWA structure.

---

If you need help hardening the off-chain side of your crypto project (wallets, backend, domains, or incident response), you can request a security-focused engagement through the Services page or reach out directly via the Contact terminal.