Skip to main content

Strata: asynchronous vaults for tokenized funds on Stellar

Iñaky
Iñaky
Strata: asynchronous vaults for tokenized funds on Stellar

When you buy into a mutual fund, the price you pay is set after you place the order. The fund calculates its share price once the market closes, your order fills at that price, and the shares usually arrive the next business day. Funds that hold private credit or real estate take longer. They value their assets only periodically, and paying out a redemption can take weeks because the cash is tied up in loans or property.

Most tokenized vaults skip the wait and price each deposit the moment it arrives, which works when the underlying asset has a live market price. Strata, the vault kit we're building on Stellar, works the way a mutual fund does. The investor requests a deposit or a redemption, the vault holds it until the fund's next valuation, and the investor claims shares or cash once the request is priced.

Key Takeaways

  • Once a redemption is priced and funded, the investor can always collect the cash, even if the operator pauses the vault or the valuation goes stale.
  • BootNode helps operators connect fund administrators, custodians and KYC providers, and take the product to mainnet.
  • The first version runs on Stellar testnet, and each operator deploys its own branded instance of the five open source contracts.
  • The Stellar Community Fund backs it with an SCF #45 grant, and SCF approved Tranche 1 in October 2026.

Why entry and exit are requests

A typical vault does two things in one transaction: it prices the share and it moves the money. A fund backed by off-chain assets can do neither on demand. The price comes from the next attestation. That is a statement of the fund's net asset value (NAV, its assets minus its liabilities) on a given date, from the fund administrator, an auditor, or the issuer. The cash for a redemption arrives when the operator has it.

Strata gives each of those its own step. The investor calls request_deposit, and the USDC goes into escrow inside the vault. When nav_oracle accepts the next attestation, the vault prices every pending request at the same NAV, and the investor calls claim_deposit to receive shares.

Redemptions take one more step, because the money has to come back from the real asset. The investor calls request_redeem, the vault prices it at the next attestation, and the operator funds it. Only then can the investor call claim_redeem and collect the cash. Because of the wait, no one gets shares at a stale price, and the vault only pays out cash the operator has put in.

If you know ERC-7540, the asynchronous vault standard on Ethereum, the flow will look familiar. Strata takes the same request-then-claim idea and builds it for Soroban, on top of the token standards and storage model Stellar already has.

Two rules the contracts enforce

A Strata vault is five Soroban contracts that each operator deploys as its own branded instance:

ContractWhat it does
async_vaultHolds escrow and runs the request and claim flows
nav_oracleAccepts the attestations that price pending requests
share_tokenThe vault share investors receive
identity_verifierChecks the allowlist when shares are minted at claim time
complianceApplies the operator's rules on who can hold and move shares

Operators can configure most of the vault, but two rules stay fixed. First, only approved addresses receive shares. The operator maintains an allowlist after KYC, the dApp only lets allowlisted addresses subscribe, and the contracts check the allowlist again when they mint shares at claim time. Second, once the vault prices a redemption and the operator funds it, the investor can always collect the cash. A pause, a delisting, or a stale valuation can't block that claim.

Operators need a way to stop new money when something looks wrong, and they will use it.

Running on Stellar testnet

The live dApp runs against contracts on Stellar testnet, covering all four investor flows: deposit, claim shares, redeem, and withdraw cash. The README lists the contract IDs and links a testnet transaction for each flow, for anyone who wants to check them on-chain.

The demo walks through the same flows from the investor's side:

Soroban behaves differently from the EVM in the places where ports tend to break: storage and TTL (how long contract data lives before it expires), auth, ledger time, events, and calls between contracts. docs/TESTING.md maps each of those to the tests that cover it. The SCF reviewers asked us to make that testing explicit.

Testnet shows the flows working end to end with stand-ins for what a real fund depends on: test USDC and test valuations, with no administrator, custodian or KYC provider behind them. Each operator brings those pieces, and connecting them is the work described in the next section.

Where BootNode comes in

We've been building web3 products since 2017. That includes StableSwap hooks for Revert Finance on Uniswap v4, the Hyperlane Warp Routes rebalancer, the Khalani integration in Nexus bridge, and Canton dAppBooster. Strata is our first Soroban project.

Strata is free and open source, and any team can deploy it without talking to us. The work around the contracts is what we do with clients:

  • Deploying a branded Strata instance, including the investor-facing app
  • Connecting a fund administrator or custodian, so valuations reach nav_oracle on schedule
  • Plugging a KYC provider into the allowlist and setting compliance rules for a jurisdiction
  • Taking the product from testnet to mainnet, including audit preparation

Because we wrote the contracts, we can walk your legal and compliance team through which settings are meant to change and which ones protect investors.

Road to mainnet

Tranche 2 continues the work on testnet. Before Tranche 3 takes the kit to mainnet, we'll apply to SCF's Audit Bank for an independent audit.

Teams planning a launch can build and test their integrations on testnet while the audit runs, and the problems they hit feed into the next tranches.

Building a tokenized fund on Stellar? Let's talk

Try the dApp, read the repo, and open an issue when something doesn't fit your case. Thanks to the SCF reviewers for feedback that shaped Tranche 1.

If you're planning a tokenized fund on Stellar and want help setting it up, let's work together.