I get a version of this question constantly, and it's usually from other developers specifically, because you're the ones who don't just want the pitch, you want to know what actually happens under the hood. So let's go through it properly.
When someone deposits ten dollars into a Wealtii fund, what actually happens between that deposit and the moment they're holding diversified exposure to crypto, tokenized gold, and tokenized tech stocks?
The basic problem: turning one deposit into a diversified basket
At a conceptual level, a digital asset index fund has to solve a problem that traditional index funds solved decades ago, just across a very different, much less standardized set of underlying assets.
A traditional index fund takes your money and buys proportional shares of whatever it's tracking, using infrastructure that's been standardized for a long time, centralized exchanges, clearing houses, custodians that all speak the same language. A fund blending crypto, tokenized gold, and tokenized equities doesn't have that luxury. Each asset class lives on different rails. Crypto trades on crypto exchanges and DEXs. Tokenized gold exposure comes from a specific issuer's token. Tokenized equity exposure comes from a completely different issuer's infrastructure. None of these were originally built to be combined into a single, seamless deposit flow.
So the actual engineering work is building the layer that takes one deposit and correctly, efficiently, and verifiably splits it across all three, according to whatever allocation that specific fund is built around.
Step one: pricing and conversion
The first real technical challenge is pricing. Before any allocation decision happens, the system needs a reliable, current price for every asset in the basket, at the same moment, so the split is actually proportional to what the fund claims to hold. Get this wrong and you're either overpaying for one asset relative to another or misrepresenting the fund's actual composition.
This means leaning on price oracles and live market data across genuinely different types of assets, a crypto price feed behaves differently than a tokenized gold price feed, which behaves differently than a tokenized equity price feed that's ultimately anchored to a traditional market's trading hours. Building this so it's accurate and doesn't silently break when one of those feeds lags or misbehaves is one of those unglamorous pieces of infrastructure that users never think about, and that I think about constantly.
Once pricing is reliable, the deposit gets converted and routed into the actual underlying assets. For small deposits specifically, this is harder than it sounds, because you're trying to avoid meaningful slippage or excessive fees when converting a ten dollar deposit across multiple asset types, several of which don't have the same deep, cheap liquidity that trading a major crypto pair does. Batching deposits and executing conversions efficiently in aggregate, rather than one small trade at a time, is part of how you keep that cost-effective instead of quietly eating a chunk of every small depositor's money in execution costs.
There's a related edge case worth mentioning, since it's the kind of thing that only shows up once real users are actually depositing real money. Markets move between the moment someone clicks deposit and the moment execution actually completes, especially during volatile periods. A system like this has to define, upfront, how much price movement is acceptable before a deposit gets rejected or flagged rather than silently executed at a worse price than the user saw on screen. Getting that threshold wrong in either direction either frustrates users with unnecessary failed deposits or quietly executes trades at prices they never actually agreed to. It's a small detail that has an outsized effect on whether people trust the platform after their first deposit.
Step two: custody
Once the underlying assets are actually acquired, they move into the fund's vault. I've written before about the specific custody model, a public, on-chain, Gnosis Safe multi-signature vault, so I won't fully re-explain that mechanism here. The relevant point for this post is that the conversion and allocation logic hands off cleanly into that custody layer, so the assets you just read about acquiring are the same assets sitting in the verifiable, public wallet, not a separate internal ledger entry that has to be trusted to match reality.
Step three: rebalancing, and being honest about where that stands
This is the part I want to be straightforward about instead of overselling, because it's genuinely still evolving.
In a fully mature version of this system, a fund would periodically rebalance itself, selling a bit of whatever's grown to outsized weight and buying more of whatever's underweight, keeping the fund's actual composition aligned with its stated target allocation over time. That's the standard behavior of a real index fund, and it's meaningfully more complex to build well across crypto, tokenized gold, and tokenized equities than it is across a single, standardized asset class.
Fully automated, continuous rebalancing across all three asset types is something I'm still actively building, not something I want to claim is fully live and battle tested today. Overstating that would be exactly the kind of gap between marketing and reality I try hard to avoid. What exists today handles allocation accurately at the point of investment. The more advanced, ongoing rebalancing logic is genuinely a work in progress, and I'd rather tell you that plainly than have a developer poke around, find it's earlier stage than implied, and lose trust in everything else I've said as a result.
The verification problem, once assets are already in the vault
There's one more piece worth walking through, because it's easy to assume "on-chain and verifiable" is a solved problem the moment assets land in a public wallet, and it's actually a little more layered than that.
Having a public address is necessary but not sufficient. The harder part is making the relationship between what the fund claims to hold and what's actually in the vault legible to someone who isn't a smart contract engineer. A raw wallet address full of token balances doesn't mean much to most people scrolling through a block explorer for the first time. Part of the engineering work here is building a layer that translates on-chain holdings into something a non-technical user can actually cross-check against the fund's stated composition, without asking them to just trust that translation either.
That's a genuinely different problem than custody or execution. Custody is about who can move funds. Execution is about how deposits become holdings efficiently. Verification legibility is about whether an ordinary person, not just someone comfortable reading contract calls, can actually confirm the first two are true without taking anyone's word for it. I think that third piece gets underrated in most "we're on-chain" pitches, because building the custody layer correctly is only half the job if nobody outside a developer audience can actually make sense of it.
Why this is genuinely harder to build solo than it sounds
If you've built anything that touches multiple external price feeds, multiple execution venues, and real user funds, you already know the failure modes I'm describing aren't hypothetical. A price feed can lag during volatility exactly when accuracy matters most. A DEX route that looked efficient in testing can behave completely differently under live market conditions. An asset issuer's infrastructure you're integrating against can have downtime you don't control and have to design around anyway.
Building this alone means every one of those failure modes is something I have to catch, understand, and handle myself, without a team to split the surface area across. It's also exactly why I default to the custody and verification model I've written about elsewhere, on-chain, public, checkable, because if something does go wrong in the allocation or execution layer, I'd rather that be visible and verifiable than quietly hidden behind a dashboard number.
If you're curious how any of this actually looks on chain
Go take a look at wealtii.com, deposit whatever amount you're comfortable with, and then go look up the resulting holdings in the vault yourself. You'll see the actual output of everything described above, not just a description of it. And if you're a developer who's built execution or custody infrastructure like this before, I'd genuinely like to hear how you handled the tradeoffs, especially around small-deposit conversion costs and price feed reliability across mismatched asset types. That's the part of this system I'm still most actively iterating on.
