A treasury manager pinged me last month after his first vault buy. The buy worked. The token showed up. He was happy. Then he tried to redeem a portion to test the round-trip. The redemption did not settle in the same transaction. He got an interface notice saying it would settle at the next NAV, and the notice did not, in his words, fill him with confidence. He thought something had broken.
Nothing had broken. The redemption was working exactly as designed. The asymmetry between buy and sell, where buy mints the token in the same transaction and sell queues for settlement at the next NAV print, is one of the most important pieces of the vault primitive, and it is also the piece that surprises the most users on first contact. So this is the explanation.
What buy actually does
When a user buys into a vault, the protocol does the following inside one transaction. It takes the user's stablecoin, computes the vault's current per-share value (which is on-chain and continuously refreshed), and mints the appropriate number of vault tokens to the user's wallet at that price. The user's stablecoin moves into the vault's accounting, the user's vault token moves into the user's wallet, and the transaction either fully completes or fully reverts. There is no partial state.
The reason this can be same-transaction is that the underlying asset, at least the on-chain part of it, is liquid. The vault has cash on hand, or the manager has positions that can be marked to a known value, and the per-share value can be computed quickly and trustlessly. Issuance is a write operation against an open accounting ledger. Same-tx works.
This is the part users expect, because it matches what stablecoin issuance looks like in their muscle memory. Send dollars, receive tokens, all at once. Vaults preserve that experience for buys.
What sell does, and why it queues
Sell is different because the vault might not have the redemption amount sitting in cash on the day the user wants out.
A vault with five hundred million dollars deployed into a lending strategy or a trading book or a tokenized credit position cannot, on demand, return ten million in cash to a single user without either selling assets or drawing on a credit line. Both have a cost. Both take time. The fair thing to do, the thing that protects the rest of the vault holders, is to honor the redemption at the next NAV print, not at the moment the request comes in.
The next NAV print is a defined event. It might be daily for liquid strategies. It might be weekly or monthly for less liquid ones. The cadence is published per vault, and the user sees it before they buy. When the print happens, the manager has had time to source the cash, and the redemption settles at the NAV that was struck at print time, not the NAV at the moment the request was submitted.
This is how every honest open-ended fund works. It is also the part of the architecture that DeFi-native users sometimes find foreign, because the rest of DeFi has been training them to expect instant exit on everything.
Why instant exit doesn't work for these strategies
There is a version of the vault primitive that does instant exit. It is called an AMM, and it works when the asset on both sides of the pool is highly liquid and the pool has enough depth that a redemption doesn't move the price. It works for, say, a liquid staking token redeeming against its underlying in a Curve pool.
It does not work for a vault holding a portfolio of tokenized real-world assets, or a delta-neutral basis trade across two exchanges, or a credit fund that has its capital deployed into a quarterly draw. In those vaults, the instant-exit model would either require the manager to keep so much cash on hand that the strategy degrades, or it would require a third party to take the other side at a discount that gets passed to the redeeming user, which is a bad outcome for the user.
The queued-redemption model accepts a small amount of friction at exit in exchange for the manager being able to actually run the strategy. We think this is the right trade. It is the trade every successful credit fund makes. It is what makes the strategy investible at all.
What the user actually sees
From the user's seat, the experience is this. They submit a redemption. The interface shows a pending state with the expected settlement window. At the next NAV print, the redemption is fulfilled at that NAV, the vault token is burned, and the stablecoin lands in the user's wallet.
The pending state is the part we worked on hardest, because it is the moment the user is most likely to think something is wrong. It shows the queue position, the expected settlement time, and the NAV that the redemption will settle against once the print happens. The user can cancel a pending redemption up until the print fires. After the print fires, the redemption is locked in.
This last piece, that the cancel window closes at the print, is important and worth saying explicitly. If users could cancel after the print, they could front-run NAV moves by canceling losses and keeping wins. That breaks the fairness of the queue. So cancel is allowed, but only before the print.
The fee shape mirrors the asymmetry
The fee structure mirrors the buy/sell asymmetry. There is no trading fee on either side of the vault. The fees are management and performance, charged against vault assets, accrued continuously, and netted against the NAV that's used for both buys and sells.
This is by design. We do not want to charge a transaction fee on entry or exit because doing so would make the vault behave like an exchange-traded asset, and that is not what it is. The vault is a continuous-pricing instrument with the entry-exit experience of an open-ended fund. The fees come from running the strategy, not from the user's act of moving in and out.
The seventy-thirty fee split between manager and protocol applies to the management and performance fees. The transaction layer is free. This is also the part of the design that is most often misunderstood, because most users come in expecting a trading-fee shape, find no trading fee, and assume something is off. There isn't. The economics live in the strategy, not in the entry.
The honest tradeoffs
I am not going to pretend the queued-redemption model is the experience users want. Most users prefer instant exit on everything. We are choosing not to give it to them on these vaults because the alternative is worse for the strategy and worse for the user holding through the strategy.
There is a version of this that we could relax for the most liquid vault categories, where instant exit is achievable without breaking the manager's ability to run the strategy. We are looking at it. The honest answer is that I think the right design will end up being a hybrid, where the most liquid vaults do offer instant exit at a small spread, and the less liquid ones keep the queued-redemption model. We have not shipped that yet. The version live today is queued across the board, because it is the more conservative starting point.
I might be wrong about which vaults can support instant exit safely. The question depends on the depth of the underlying market and the manager's ability to maintain a liquidity buffer, both of which change over time. I would not want to commit to a per-vault answer in writing until we have more data on actual redemption patterns. The thing I am confident about is that the asymmetry between buy and sell is structural, not arbitrary, and the user who understands it ends up trusting the vault more than the user who hits redeem and is surprised when it doesn't settle in the same block.
