# Generation Flow

This document describes our approach of transforming the list of outputs associated with an account into an activity history. The following approach and the related architectural design choices have its limitations. The corresponding sections address these.

# Activity Initialization

After syncing all of the accounts, the accounts contains outgoing transactions and incoming outputs. These objects are highly nested and too complex for a non-technical user to understand and draw simple conclusions from them (e.g. Who was the sender/receiver? Do I have to claim that first?).

The first step is to transform both transactions and outputs into activities. Transactions contain the most information, so these have the highest priority for the activity overview.

# Transactions

With transactions we can build complete activities.

Currently we only have outgoing transactions. Soon we will also get transactions attached to the incoming outputs, allowing us to add more information to these activities as well.

Important: They are guaranteed to persist in wallet.rs, but not on the nodes. This means we can lose the information and therefore need a fallback option.

# Outputs

If transactions were pruned on the nodes, and we restore a profile, we cannot access them anymore. For this case, we fallback on creating activities from pure outputs. These contain no information about its origin, so there's no way to compute the sender for incoming ones.

Additionally we don't have outputs generated by transactions initialized by us.

# Activity Post-Processing

The previous step initialized all activities. But activities on their own are missing some important UX properties, because they can only be deduced by comparing them with each other. Depending on the result of such a comparison, some activities get updated, while others get hidden to not confuse the user.

Currently we have 2 post-processing steps, but this list can be expanded if new requirements arise.

# Claimed Activity

Activities can be claimable because of different reasons: a contained storage deposit, expiration date, etc. Claiming one always results in a new transaction, consuming the claimable activity and resulting in an output to the corresponding account.

# Incoming

We can compute incoming, claimed activities because we have all incoming outputs (which contain the claimable activities) and outgoing transactions (which includes the claiming activity).

Find Matching Pair: For each async activity A1 another future activity A2 is searched, that contains A1 as an input. If one is found, we have a match.

Result: Claimed activity A1 gets updated, claim status is set to true, claim time and claim id will be updated to the claiming transactions infos. Claiming activity A2 gets hidden

# Outgoing

Currently not implemented / not possible. We can compute which of the activities result in a claimable activity for the receiver account, but we have no way to check if they consumed it.

# Storage Deposit Return

Sending small funds result in a storage deposit. When the receiving account claims the funds, they send a transaction back to the original sender containing that storage deposit return (SDR).

Find Matching Pair: For each activity A1 with a SDR, we narrow the potential SDR activities down by some conditions (currently: Candidate happened after A1. Candidates amount needs to be the same as the storage deposit). These candidates need to be checked around 2 corners: If the input of the input of the candidate is A1, we have a match.

Result: Activity containing the storage deposit gets updated, storage deposit gets crossed out in detailpopup. Return activity gets hidden

# Preparation for Overview

After creating and post-processing the activities, they are being prepared for the UI. Depending on the selected account, inserted search term or active filter, a corresponding subset of all activities is displayed, after being grouped together by the transaction time.