@criptix
Let me give you an example of how this will work, to clarify further:
Firstly, my answer above is as correct, but technically there is more to it. In the Tagion network, users do not have one or more wallets in the system. Instead, each user owns one or more private spend keys that can unlock their Tagions on the network for use.
Now, for shards - in Tagion, we call a Shard a Sub-DART, as this is technically more correct, as there is more to it than what you have going for traditional database shards. So, I'll be using the term Sub-DART in the following. And now, let's get to it:
As a rule, all Tagions exist in the Main DART. When - for various reasons - it makes sense to have some Tagions assigned to a particular Sub-DART (an example could be Alice's wallet assigning 10 Tagions to Sub-DART A that covers a certain geographical region, optimizing this for transaction speed), the 10 Tagions in the Main DART are locked and then assigned to the Sub-DART.
Now, when Alice, through her wallet pays 5 Tagions to Bob, her own 10 Tagions are destroyed, 5 new are made for herself, 5 new are made for Bob, and Sub-DART ledger entries (anonymous) are updated accordingly. Only once Alice or Bob, or anyone else that may have received Tagions out of Alice's original 10, have their wallet (or software), making a transaction out of Sub-DART A, the Main DART is updated.
This - rather complex setup - helps optimizing transaction speed and reduces the number of required transactions to move funds around, to a minimum.
The transactions that take place and the split of the Tagions in the Sub-DART are all secured by the use of cryptographic signatures, and the Sub-DART ledger makes sure that the locked Tagions in the Main DART ends up in the right place, once transactions happen through it.
Luckily, the above is invisible to the end-user. The user experience will be that you, through your wallet or other software, request to make a payment or transfer of Tagions to another, and then this happens within a few seconds.
This is - btw - also the same pattern that is used for our DEX (decentralized exchange).
There is not a function that allows for sharing a high transaction workload with other Shards. As the above explains, it will take a transaction out of the Sub-DART, to move Tagions. And then, why not just use the transaction to finalize what needs to be done?
Another thing is that it would be a very positive situation, if we have a "Sub-DART tx overload" situation, as each Sub-DART will be capable of handling thousands of transactions per second and have a transaction fully processed within a few seconds.
We are looking very much forward to test exactly how many thousands of transactions shortly, as we've made quite some updates to the protocols. Our simulations will take place on the Alpha network, and we're hoping to hit only easy solvable bottlenecks - but let's see
