[Rn.1.1] As Request Network, I should be able to track the use of the protocol via hex #170
Description
The following user stories define the traceability and analytics capabilities needed for Request Network to understand how the protocol is being used.
As Request Network, I should be able to see the total number of destinations that have been claimed across the entire protocol so that I can measure overall adoption of the system. A claimed destination represents a wallet that has registered a receiving destination within the Request dashboard.
As Request Network, I should be able to see the number of active destinations per day. An active destination is defined as a destination that has had at least one transaction created or processed during that day. This metric allows the team to measure daily protocol activity and real usage of the infrastructure.
As Request Network, I should be able to see the number of active destinations per week. An active destination for a given week is a destination that has processed at least one transaction during that week. This provides a clearer view of sustained usage and avoids distortions caused by short-term fluctuations in daily activity.
As Request Network, I should be able to track the total amount collected per destination over time. This data should allow the creation of a leaderboard showing the lifetime value of payments collected per destination. The destination must always be linked to the wallet that owns it and not to the specific receiving route. This means that if a user changes their receiving route, for example from USDT on Ethereum to USDC on Base, the collected volume must still be attributed to the same destination wallet.
As Request Network, I should be able to visualize the distribution of claimed destinations by blockchain network. This should be represented as a pie chart that shows the pool of destinations claimed per chain, allowing the team to understand which ecosystems users are onboarding from.
As Request Network, I should be able to see how many destinations are managed by each Client ID. This helps identify which orchestrators or integrations are responsible for managing large numbers of destinations and provides visibility into which partners are driving adoption of the protocol.
As Request Network, I should be able to see how many transactions are created by each Client ID under the destinations they manage. This allows the team to measure the activity level of orchestrators and understand which integrations are generating the most payment requests and transaction flow within the network.