Storage Deposit Returns in Transfers
Stardust introduces a new system to protect the ledger size and hence node storage resources, called Byte-cost based Storage Deposit System. You can read more about it in TIP-19. In short, every output in the ledger need to carry enough base tokens to cover for its network storage use.
Implicitly this means that an output has to have a minimum amount of base tokens, otherwise it is considered invalid. The exact minimum depends on the size of the output and the protocol parameter Virtual Byte Cost. The implication of this is that is no longer possible to store microfunds in an output. So suppose you wanted to send 1i (0.000001 MIOTA): is it still possible?
The answer is yes. With the Storage Deposit Return Unlock Condition it is possible to define spending constraints on outputs that you create. Let's assume that the minimum amount of funds that need to be present in an output is 100i. If you wanted to send only 1i to the recipient, you should transfer 101i to the recipient's address with the extra condition that recipient can only use the funds if the recipient refunds you in the very same transaction with 100i.
Example Transactions
Send a Micro-transaction
Transaction G show the creation of an output with Storage Deposit Return Unlock Condition. Notice, that Basic Output #11 holds 101i, and the unlock condition defines the Return Amount of 100i to ReturnAddress ownerAddress. All in all, the recipient can only freely use 1i when recipient consumes the output in Transaction H.
Receive a Micro-transaction
In order for the recipient to claim the 1i, the recipient needs to sweep it into one of their own outputs. Therefore, the recipient consumes Basic Output #12 in the transaction that holds the funds. On the output side, the recipient has to have Basic Output #13 that refunds the original sender, and create Basic Output #14 that sweeps the 1i.
What forces the recipient to post and execute Transaction H? Nothing. The recipient can just keep the sender's 100i in limbo forever. That is why it is handy that you can combine unlock conditions. For example, the sender can add an expiration condition to Basic Output #11. Once the output is expired, the recipient won't be able to claim the 1i and the sender takes full custody of the 101i in the output.