If a fund holds three completely different kinds of assets, crypto, tokenized gold, and tokenized equities, how does it actually know what one unit of that fund is worth right now, at this exact second, in a way you can trust. That question turns out to be a genuinely interesting engineering problem, and almost nobody outside the fund itself explains how it actually works. 📊
Let's fix that.
Start with NAV, because everything else builds on it
Net asset value, NAV, is not a crypto native idea. Traditional mutual funds have calculated it for decades: total value of everything the fund holds, divided by the number of units outstanding, equals the value of one unit. Simple in concept. The entire engineering challenge is keeping "total value of everything the fund holds" accurate in real time when that basket includes assets that do not all trade the same way, on the same schedule, or on the same venues.
A traditional fund can get away with calculating NAV once a day, after markets close, because traditional markets have a close. Crypto does not close. If your fund holds crypto, gold, and equities together and you want NAV to mean something continuously, you need live pricing for all three, all the time, and you need it to be honest.
Why each asset type is a different pricing problem
Crypto pricing is the most straightforward of the three, relatively speaking. Liquid tokens trade continuously across many exchanges, and aggregating price feeds across venues is a well understood problem with mature tooling behind it.
Tokenized gold pricing is one layer removed. A token like Tether Gold, XAUT, trades on its own exchanges with its own live price, but that price is also supposed to track the spot price of physical gold. So there are actually two things worth checking: what the token trades at right now, and whether that price is staying sensibly close to the physical gold market it is meant to represent.
Tokenized equity pricing is the hardest of the three, because the token is deliberately trying to mirror something happening in a completely different market structure, traditional equities, which does have trading hours and does close. A tokenized stock still needs a price outside those hours, which means the system needs a sensible way to handle valuing the position when the underlying market it tracks is not even open, generally by holding the last confirmed price until trading resumes, rather than inventing a number.
None of these three problems get solved by the same mechanism, and a fund that pretends they do is skipping the hard part.
Where oracles come in
This is the part that actually matters for trust, not just architecture. A smart contract cannot reach outside the blockchain and check a price by itself. It needs something to feed it that information, reliably, and that something is generally called an oracle.
The naive version of an oracle is a single price feed from a single source. That is also the version most vulnerable to manipulation, because a single point of failure in a pricing system is a single point of attack. If a bad actor can influence one exchange's price for a few seconds, and your entire fund NAV depends on that one feed, you have built a system with a very specific, very findable weak point.
The more robust version, and the one that matters here, pulls prices from multiple independent sources and aggregates them, typically through a median or weighted average, so a temporary distortion on one venue does not distort the whole system. Serious oracle networks, the kind used broadly across DeFi for exactly this reason, also apply staleness checks, refusing to trust a price feed that has not updated recently, and deviation thresholds, flagging a price that moved further than expected in too short a window.
What happens when a price feed actually fails
Design for the failure case, not just the happy path, because the failure case is where trust either survives or does not. A well built system needs an explicit answer to what happens the moment a price feed goes stale, returns an obviously wrong number, or simply stops responding.
The naive failure mode is silently falling back to whatever the last known price was and pretending nothing happened. That is the worst option, because it looks fine right up until it very much is not, and by the time someone notices, trades may have already executed against a bad number. A better approach treats a stale or missing feed as a signal to pause the specific action that depends on it, a rebalance, a redemption calculation, rather than quietly proceeding with degraded information. Circuit breaker patterns, the same concept used broadly in distributed systems engineering, apply directly here: if a dependency is unhealthy, stop relying on it and fail loudly rather than fail silently.
This is also where redundancy actually earns its cost. Running multiple independent oracle sources is more expensive and more complex than running one, and that complexity is precisely the point. A system that only works when every dependency behaves perfectly is not a resilient system, it is a demo that has not met a bad day yet.
Why rebalancing depends entirely on getting this right
If a fund maintains target allocation percentages across its assets, crypto, gold, and equities, rebalancing back to those targets requires knowing the current NAV accurately before executing any trade. Rebalance against a stale or manipulated price, and you are not correcting the allocation, you are actively distorting it based on bad information. This is also where trade execution itself becomes a technical problem worth respecting, because a large rebalancing trade executed carelessly can move the very price it depends on, which is its own category of risk separate from oracle manipulation entirely.
A system built carefully here treats price accuracy as a prerequisite for every downstream calculation, not an assumption you get to make once and move on from.
Why this is a different trust question than proof of reserves
If you have read anything about on-chain proof of reserves, this might sound familiar, but it is actually a distinct problem. Proof of reserves answers "does the fund actually hold what it says it holds." NAV and oracle integrity answer a different question entirely: "is the price you are being shown for your position actually honest right now." You can have perfectly verified reserves and still get a wrong answer to what your position is worth, if the pricing layer feeding that number is weak. A fund worth trusting needs to get both right, and they require genuinely different engineering solutions.
Why this matters for how Wealtii is built
Pricing a fund that spans crypto, tokenized gold, and tokenized equities means solving three different pricing problems honestly rather than reaching for one convenient shortcut and hoping it holds across all three. Crypto and tokenized assets remain volatile regardless of how accurate the pricing mechanism is, oracle systems carry their own operational risk, and none of this is financial advice.
If you want to think through how you would build this yourself, start with the question that actually matters: what happens to your NAV calculation the moment one of your price feeds goes stale, and does your system notice before your users do. That question, more than any single line of code, is what separates a pricing system built to be trusted from one built to just work in the demo. wealtii.com is live if you want to see where that question actually gets answered in production. 🔧
None of this is the part anyone puts on a landing page. Nobody writes marketing copy about deviation thresholds or fallback pricing logic. But the fund's entire promise, that the number you see is the number that is actually true, lives or dies in exactly this layer, and it deserves more scrutiny than a single line claiming the platform is "real time" and leaving it there.
Top comments (0)