Share
Explore

icon picker
PRD | Alluvial Finance Reporting API Enhancements

Bringing a competitive edge to Alluvial Finance's Reporting API.

Goal: Identify the most impactful feature(s) identified in the gap analysis and write a Product Requirements Document (PRD) to execute with the engineering team
Team: Product Manager, Tech Lead, Designer, Engineer
Contributors: Product Manager, Tech Lead
Consulted: Marketing, Customer Success, Sales, Strategy
Status: Not Started
Launch Date: TBD

Objective

Overview & Background ​Rewards Reporting API is lacking critical table-stakes and Quality of Life functionality. Users are the engineering teams at banks, hedge funds, private offices, etc. and their business partners. ​Our objective: implement comprehensive reward history, daily reward summaries, detailed validator performance data, account information, staking rewards, validator details, and transaction history endpoints in Alluvial’s Reporting API to provide institutions with the necessary tools for thorough financial reporting, compliance, and performance monitoring.

🎯 Goals & Metrics

Success Metrics
0
Objective
key Results
1
DMU
~ # of API method usage
2
WMU
~ # of API method usage on a weekly basis
3
MMU
~ # of API method usage on a monthly basis
4
User Adoption Rate
The number of new and existing clients utilizing the new features within the first six months.
5
Customer Satisfaction:
Feedback from institutional clients through surveys and direct feedback channels.
6
Performance Metrics
Reduction in support queries related to reporting and data tracking, indicating ease of use and reliability.
7
Business Impact
Increase in the volume of staking activities and the number of institutions joining the Liquid Collective due to the enhanced reporting capabilities.
There are no rows in this table

Non-Goals

UI/UX Focus
Integration with External Financial Systems
Introduction of New Blockchain Networks
Advanced Predictive Analytics
Data Export to Proprietary Formats
Custom Report Generation Services

📝 Requirements & Scope

Feature Name
Benefit hypothesis
Priority
Notes
1
Staking Rewards
Detailed breakdowns of staking rewards earned by accounts are necessary for income reporting and performance tracking.
1
Open
2
Reward History Endpoint
Institutions need detailed historical data on staking rewards for financial reporting and audit purposes.
2
Open
3
Daily Reward Summaries
Summarized daily data helps institutions quickly understand their daily earnings and track performance.
3
Open
4
Transaction History
Complete transaction histories are vital for audits, compliance, and internal reviews.
4
Open
5
Account Information and Balances
Comprehensive account data, including balances and asset holdings, is essential for financial planning and reporting.
5
Open
6
Validator Performance Data
Detailed performance metrics for validators are crucial for assessing the reliability and efficiency of staking operations.
6
Open
7
Validator Information
Detailed information on validators aids in compliance and decision-making processes.
7
Open
There are no rows in this table

Workflows

Business Process Flows

Process Flow 1: Data Retrieval and Reporting
Data Collection: Alluvial API collects data from blockchain and validators.
Data Storage: Data is securely stored in Alluvial’s database.
API Requests: Institutions send API requests for specific data (rewards, balances, transactions).
Data Processing: API processes the request and retrieves relevant data.
Data Delivery: API delivers the requested data to the institution’s dashboard or system.
Report Generation: Institutions generate reports using the provided data.
Process Flow 2: Alerts and Notifications
Event Detection: API monitors for specific events (e.g., reward distribution, validator performance changes).
Alert Configuration: Institutions configure alerts for specific thresholds or events.
Notification Trigger: When an event meets the configured criteria, the API triggers a notification.
Alert Delivery: Notifications are sent to the institution via email, SMS, or dashboard alerts.
Response: Institutions take action based on the received alerts.

❗Design Considerations

Scalability: Ensure the API can handle a large number of concurrent users and data points, especially during peak times.
Security: Implement robust security with elegant onboarding flow to ensure the integrity and confidentiality of the data while minimizing friction.
User Experience: Ensure that the endpoints are intuitive and easy to integrate with existing systems used by institutional clients.
Compatibility: Ensure seamless compatibility with existing financial systems and platforms used by institutional clients by following industry standard reporting models.

Open Issues & Key Decisions

Question
Answer
Owner
Notes
1
Open
2
Open
3
Open
4
Open
There are no rows in this table

🚀 Launch Plan

Key Milestones

Date
Milestone
Description
Status
1
On-Track
2
In-Progress
3
Launched
There are no rows in this table

Launch checklist

Prepare for the product launch - Area|Action Item|Instructions
Area
Action Items
Instructions
Owner
Due Date
1
Go-To-Market Strategy
Define Marketing strategy
2
Legal
3
Customer Success
4
Compliance
5
Sales
6
Reporting & Analytics
There are no rows in this table

📁 Documentation/Reference Links

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.