How would I best model a payments system comprised of user, wallet and transaction receipt aggregates?

Context
Users have their data persisted as streams:
User-[unique guid]

System has a list of financial assets as streams:
Asset-[unique symbol, e.g. BTC or ETH]

As well as streams for tracking inflows:
Inflow-[unique symbol, e.g. BTC or ETH]-[transaction ref/hash]

Each user is meant to own exactly one wallet each of all assets:
Wallet-[asset symbol]-[user guid]

This is what I’ve mapped out in an attempt to model a system where users can keep multiple digital wallets, deposit funds into these wallets as well as transfer between themselves.
A background job is meant to traverse say the Ethereum blockchain to discover ETH deposits, which it writes to the inflow stream, for instance:
Inflow-ETH-0x67c97d7b8cd2be88d15535198d7e61315e08846618e6a1417d8206f88535bfa3

I’ve gone ahead and written a projection that links the inflow event from this stream to the wallet stream whose deposit address matches that in the transaction, but not quite.
A projection cannot emit to an existing stream, I’ve learned, so for wallet stream:
Wallet-ETH-19fd0b8b-ed87-4b4c-a96d-9d0bd580e38c
I’ve had to link inflows to stream:
Wallet-ETH-19fd0b8b-ed87-4b4c-a96d-9d0bd580e38c-inflows

That poses a problem:
While hydrating the wallet aggregate, the stream ID I read is:
Wallet-ETH-19fd0b8b-ed87-4b4c-a96d-9d0bd580e38c
And the only way to see the inflows from Wallet-ETH-19fd0b8b-ed87-4b4c-a96d-9d0bd580e38c-inflows (which I need to resolve the wallet’s balance), I’d have to read $ce-Wallet and filter (in business logic) events whose stream ID starts with “Wallet-ETH-19fd0b8b-ed87-4b4c-a96d-9d0bd580e38c-”

That hack of a solution is probably the only thing I can think of because this whole model is flawed, so I seek guidance and advise.
My primary questions are:

  • Is it safe to model the inflow stream that way? The implication being that a trillion deposits would potentially occur for each inflow stream, ergo a trillion different streams with just one event each.
  • Are projections the best way to solve this, and how, if it is? The point being that not being able to emit to an existing stream sort of blocks my capacity to see how I can leverage projections here.
  • Again, if projections are the answer, what happens to linked events when projections are modified or completely replaced? The wallet aggregate will forever need those linked events to resolve the user’s balance, so what happens when the projection that linked inflow events from the inflow stream to the wallet stream?

Please, help me make sense of this.

the bes thing would be to seperate ingress data (inflow) from the data in the operational system (user / asset / wallet)

e.G : 1 store to keep the ingress data, a worker process subscribe to it and writes to a second store where the operational data is kept.
this allows for the ingress to be completely independent of the rest as wel as aggressive scavengin/deletion of ingress data once it’s been processed into the operation system.